Provisionis in the Healthcare IT Industry

Provision

provision

Need to provide database self-service to internal teams? Can't spare the resources to build and maintain your own private DBaaS solution? Sick of cloud DBaaS providers locking you in? is a cloud-native database platform to deploy and manage enterprise-grade PostgreSQL, MongoDB and MySQL database clusters. Percona Everest With Percona Everest, you can: Enable DBA teams to regain control over data and database configuration Empower developers to deploy code faster and self-service provision highly performant, production-ready database clusters Free your entire organization from vendor lock-in and restrictive subscriptions Benefits of Percona Everest Truly , Percona Everest offers the benefits of automated database provisioning and management without the need to build or maintain an in-house database management platform. open source No data lock-in or restrictive contracts Reduced total cost of ownership (TCO) Complete data sovereignty to meet any compliance requirement Fully customizable database configurations Right-sized database deployments Frictionless developer self-service Backing of highly skilled database management experts Key features of Percona Everest Database management via a single pane of glass Percona Everest enables you to manage complex database environments through a single pane of glass or API. Create, configure, deploy, update, and upgrade with zero downtime Backup, restore, restart, suspend/resume, or delete database clusters Complete customization Customize load balancing settings, settings for network exposure, and resource settings like node count, instance type, CPU, memory, storage, etc. Standardized database deployments Create ready-to-use database clusters of enterprise-grade MySQL, PostgreSQL, and MongoDB, with the ability to customize to support a variety of topologies or deployments. Percona Everest leverages to deploy Cloud-Native Percona Distributions. Percona Operators Built-in observability tools Benefit from built-in open source infrastructure monitoring to keep control of (and optimize) resource usage, health, and performance of database clusters. How Percona Everest is designed Percona Everest has two primary components Percona Everest application with the UI On the frontend, there is a Percona Everest UI which is developed using the Vite framework, React library and TypeScript language. On the backend, requests from the frontend app are processed by Percona Everest Backend. It is an API developed in Golang using the Echo framework that sends requests to the Kubernetes API. You can also use the API directly for your needs. Percona Everest CLI (everestctl) You can install Percona Everest operators and components to your Kubernetes Cluster with the help of a console tool Percona Everest CLI (everestctl). Then, Percona Everest will create and manage database clusters. Everestctl is developed in Golang, and it is a built-in executable file. Percona Everest does not supply a Kubernetes cluster; you’ll need to use your own for the deployment. Percona Everest is currently in Beta We invite you to become an early adopter and contribute to progress! Your feedback is crucial to enhancing the software, and we highly value and rely on your input. Percona Everest website Documentation Quick Start Also published . here

A New Way to Provision Databases on Kubernetes

Liquidity provisioning in Uniswap V3 presents a stochastic optimal control problem with a well-defined utility function to maximize. This article introduces an innovative framework for intelligent liquidity provisioning, utilizing a combination of agent-based modeling and reinforcement learning. Our framework provides a robust and adaptive solution for optimizing liquidity provisioning strategies. The Uniswap V3 model mimics real-world market conditions, while the agent-based model (ABM) creates an environment for simulating agent interactions with Uniswap V3 pools. The reinforcement learning agent, trained using deep deterministic policy gradients (DDPG), learns optimal strategies, showcasing the potential of machine learning in enhancing DeFi participation. This approach aims to improve liquidity providers’ profitability and understanding of CFMM markets. Content Overview Introduction Intelligent liquidity provisioning framework Components of Intelligent Liquidity Provisioning Framework Agent-based simulator Reinforcement Learning Model Limitations Future Work Conclusion Resources References Introduction In my previous article on market making we explored the mechanics and strategies of market making in traditional financial markets. Building upon those insights, this article introduces an innovative framework for intelligent liquidity provisioning in the context of Uniswap V3. As mentioned in our prior research, our goal was to extend our understanding of market dynamics and liquidity management in decentralized finance ( , specifically through the development of the Intelligent Liquidity Provisioning Framework. [Market Making Mechanics and Strategies], DeFi) Decentralized finance (DeFi) has undergone remarkable growth, introducing innovative financial products and services accessible to a global audience. Uniswap V3, at the forefront of this innovation, has revolutionized liquidity provisioning with its concentrated liquidity feature. However, this advancement brings forth complex decision-making challenges for liquidity providers. This article introduces a comprehensive framework designed to address these challenges, offering a simulated environment for studying and optimizing liquidity provisioning strategies. Our framework comprises three key components: the Uniswap V3 model, an agent-based model (ABM), and a reinforcement learning agent. The Uniswap V3 model provides a representation of the pool, enabling the deployment and interaction with tokens and pools. The ABM introduces complexity by simulating agent interactions and market dynamics, creating a rich environment for strategy evaluation. The reinforcement learning agent, operating within this environment, adopts a deep deterministic policy gradient approach to learn and adapt strategies, aiming for optimal performance in liquidity provisioning. This research aims to develop an intelligent liquidity provisioning (ILP) mechanism using reinforcement learning (RL) to autonomously manage and optimize liquidity within the Uniswap V3 environment. The mechanism seeks to maximize the utility function, considering fees earned, impermanent loss, and other metrics based on liquidity providers’ preferences while adapting to the complex dynamics of the CFMM market. Intelligent Liquidity Provisioning Framework In the RL framework, the liquidity provisioning problem is formulated as a Markov Decision Process (MDP). The MDP consists of states, actions, and rewards. States represent the current market conditions, including asset prices, trading volumes, and other relevant variables. States: Actions correspond to the decisions made by the liquidity provider, such as adjusting liquidity allocations, rebalancing portfolios, etc. Actions: Rewards quantify the desirability of the outcomes based on the liquidity provider’s objective function, preferences, and constraints. The rewards can be positive for desirable outcomes (e.g., high returns) and negative for undesirable outcomes (e.g., high risk or underperformance). Rewards: The objective function represents the liquidity provider’s desired outcome, which can be a combination of factors like maximizing returns, minimizing risks, or achieving a specific trade-off between the two. Constraints can include limitations on liquidity allocations, capital utilization, risk tolerance levels, or other restrictions defined by the liquidity provider. Objective Function: RL training is an iterative process where the agent continuously updates its policy based on feedback. The agent learns from its experiences and refines its decision-making over time, gradually converging to more optimal liquidity provisioning strategies. Once the RL agent has been trained, it can be tested and evaluated using historical data or simulated environments to assess its performance against the liquidity provider’s objective function and constraints. The agent’s performance can be measured using metrics like returns, risk measures, or other relevant performance indicators. By applying RL algorithm, the liquidity provisioning mechanism can learn and adapt to changing market conditions, identify optimal liquidity provision strategies, and balance constraints and preferences specified by the liquidity provider. RL enables the mechanism to find solutions that maximize the liquidity provider’s objective function, considering various trade-offs and constraints autonomously and dynamically. Components of Intelligent Liquidity Provisioning Framework The framework comprises three major components: UniswapV3 Model The Uniswap V3 model implemented in Python offers a detailed and functional simulation of the Uniswap V3 protocol, capturing its nuanced mechanics and providing users with a comprehensive toolset for interacting with the protocol. The UniswapV3_Model class handles the deployment of tokens and pools, initializes pools, and provides an interface for pool actions and pool state retrieval. Overview The Uniswap Model serves as the foundation of the Intelligent Liquidity Provisioning Framework, encapsulating the core mechanics of Uniswap V3. It leverages compiled smart contracts from Uniswap’s V3-Core, deployed in a local Ganache environment using brownie, to create a realistic and interactive simulation. Contract Compilation and Deployment The framework integrates with Brownie, a Python-based development and testing framework for smart contracts, to compile and deploy the Uniswap V3 smart contracts. These contracts are then deployed to a local Ganache environment, providing a sandbox for testing and development. This setup ensures that users can interact with the Uniswap environment without the need for real assets or network transactions, fostering a safe and controlled experimentation space. Agent-Based Simulator is used to simulate the Uniswap V3 environment, agent policies are defined to incorporate the dynamics of Uniswap market participants. Different types of agents are used to simulate the dynamic Uniswap environment Tokenspice agent-based simulator Introduction simulates the actions and interactions of individual agents within the Uniswap V3 ecosystem. By modeling the complex behaviors of different participants, the ABM provides a comprehensive interface of Uniswap V3 dynamic environment, enabling the analysis and optimization of liquidity provisioning strategies. Tokenspice Agent-Based Model (ABM) Agent Types and Behaviors The ABM includes various agent types, each representing a specific role within the Uniswap V3 ecosystem. The two main agents are the Liquidity Provider Agent and the Swapper Agent, which interact with the Uniswap pools to provide liquidity and perform token swaps, respectively. The behavior of these agents is dictated by policies defined in the file, ensuring that their actions are aligned with real-world strategies and market conditions. agents_policies.py This agent adds and removes liquidity from the Uniswap pools. It follows a set of policies that dictate its actions based on the current state of the market and the agent’s preferences. Liquidity Provider Agent: The Swapper Agent performs token swaps within the Uniswap pools, taking advantage of price discrepancies and arbitrage opportunities. Its behavior is guided by policies that assess the potential profitability of trades, considering transaction fees and slippage. Swapper Agent: Simulation Configuration and Execution The file is central to the ABM, configuring how agents interact with each other and with the Uniswap pools. It defines the relationships between agents, policies, and the simulation environment. netlist.py The , , and modules provide the foundational elements for running simulations. The SimEngine orchestrates the simulation, managing the flow of time and the execution of agent actions. The SimStateBase maintains the current state of the simulation, storing data on agent holdings, pool states, and other relevant variables. The SimStrategyBase defines the overarching strategies that guide agent behavior throughout the simulation. SimEngine.py SimStateBase.py SimStrategyBase.py Reinforcement Learning Model Introduction The Reinforcement Learning (RL) Agent is a pivotal component of the Intelligent Liquidity Provisioning Framework, designed to interact with the Uniswap V3 ecosystem through Uniswap Model an agent-based model. This section delves into the RL Agent, its environment, and the DDPG (Deep Deterministic Policy Gradient) algorithm used for training. RL Agent Environment The RL Agent operates in a custom environment, , which interfaces with the Uniswap model and the agent-based model to simulate the DeFi market. This environment facilitates the agent’s interaction with Uniswap pools, allowing it to add and remove liquidity, and observe the consequences of its actions. The RL Agent interacts with the Uniswap model and ABM to simulate real-world liquidity provisioning in Uniswap V3. It chooses actions that result in adding or removing liquidity, with policies and simulation configuration defined in the ABM, ensuring realistic interactions. DiscreteSimpleEnv The environment’s state space includes various market indicators such as the current price, liquidity, and fee growth. These parameters are normalized and provided to the agent at each timestep. State Space: The agent’s action space consists of continuous values representing the price bounds for adding liquidity to a Uniswap pool. These actions are translated into interactions with the Uniswap pools, affecting the state of the environment. Action Space: The reward function is crucial for training the RL Agent. It takes into account the fee income, impermanent loss, portfolio value, and potential penalties, providing a scalar reward signal to guide the agent’s learning process. Reward Function: DDPG Agent The DDPG Agent is a model-free, off-policy actor-critic algorithm using deep function approximators. It can handle high-dimensional state spaces and continuous action spaces, making it well-suited for our Uniswap V3 environment. This network is responsible for providing the best-believed action given a state. It has a sigmoid output layer, outputting relative values for and which are then scaled to the desired range in agent env, representing the price bounds for adding liquidity. Actor Network: price_lower price_upper This network evaluates the action value function, estimating the expected return of taking an action in a given state. Critic Network: DDPG employs target networks for both the actor and critic, which are slowly updated to stabilize training. Target Networks: This technique is used to store a replay buffer of past experiences, allowing the agent to learn from a diverse set of samples, breaking correlations in observations, and smoothing out learning. Experience Replay: Interaction with Uniswap Model and ABM The RL Agent leverages the Uniswap model and agent-based model to simulate real-world liquidity provisioning in Uniswap V3. It interacts with the Uniswap pools through the , performing actions that result in adding or removing liquidity. The agent’s policies and the simulation configuration are defined in the ABM component, ensuring a realistic and coherent dynamic environment. DiscreteSimpleEnv The agent is trained over a series of episodes, each representing a different market scenario (different pool). The agent’s performance is evaluated based on its ability to maximize returns while minimizing risks associated with liquidity provisioning. The effectiveness of the Intelligent Liquidity Provisioning Framework is assessed through the evaluation of the reinforcement learning (RL) agent’s performance. Train and Evaluate Agent: To evaluate the RL agent, we set up a specialized evaluation environment, , which extends the base environment, . This environment is tailored for the evaluation of agent policies. Environment Setup: DiscreteSimpleEnvEval DiscreteSimpleEnv In our evaluation setup, we compare the RL agent’s performance against that of a baseline agent. The baseline agent’s actions are determined by a baseline policy that relies on the current state of the liquidity pool. This agent aims to provide a reference point for evaluating the RL agent’s performance. Baseline Agent: Results Training Evaluation Limitations Currently, the framework does not fully capture the real-time synchronization of pools, which can lead to discrepancies in modeling real Uniswap V3 dynamics. Future work should focus on incorporating mechanisms for better pool synchronization, potentially utilizing tick/position data or events to enhance realism. Pools Synchronization: The agent policies employed in the current framework are relatively simple and naive. To achieve more accurate simulations, future iterations should aim to define more comprehensive agent policies. These policies could model various types of Uniswap agents, such as noise traders, informed traders, retail liquidity providers, and institutional liquidity providers. Alternatively, statistical models trained on historical pool data can inform agent policies for more realistic behavior. Naive Agent Policies: The observation space provided to the agents lacks comprehensive information about the state of the pool. To improve decision-making capabilities, future enhancements should include tick and position data, along with engineered features that offer agents a more comprehensive understanding of the pool’s status. Sparse Observation Space: The action space for agents is currently constrained, with fixed liquidity amounts and restricted price range bounds. Expanding the action space to allow for more flexibility in liquidity provision, as well as considering multiple positions per step, can enhance the fidelity of the simulations. Limited Action Space: Future Work Agent Environment: Implement mechanisms to synchronize pools, possibly using tick/position data or events, to create more realistic dynamics in the Uniswap V3 environment. Synced Pools: Actor/Critic Network Architecture, alpha, beta, tau, batch size, steps, episodes, scaling parameters (rewards, actions, observation space) Hyperparameter Tuning: Define more sophisticated analytical policies that accurately model various Uniswap agents or utilize statistical models trained on historical pool data to inform agent behavior. Comprehensive Agent Policies: Enhance the observation space by including tick and position data, and engineer features that provide agents with a comprehensive view of the pool’s state. Informative Observation Space: Develop an improved reward function that accounts for a wider range of factors, leading to more effective agent training. Improved Reward Function: Instead of one position with a fixed budget at each timestep, implement a more comprehensive mechanism in which the agent is allocated a budget once at the start of the simulation and then learns to use this budget optimally in subsequent steps. Multiple Positions: Define more comprehensive baseline policies to evaluate the performance of the RL agent Baseline Policies: Agent Algorithm Further refine and optimize the hyperparameters of the reinforcement learning agent for better training performance. Hyperparameter Tuning: Explore alternative RL agent models, such as Proximal Policy Optimization (PPO) or Soft Actor-Critic (SAC), to determine if they offer advantages in specific scenarios. Experimentation with Other RL Agents: Investigate the application of multi-agent reinforcement learning techniques, which can be beneficial for modeling interactions among multiple liquidity providers and swappers. Multi-Agent RL (MARL): Implement online learning strategies that allow agents to adapt to changing market conditions in real time, providing a more dynamic and adaptive liquidity provisioning solution. Online Learning: Conclusion In the rapidly evolving landscape of decentralized finance (DeFi), liquidity provisioning plays a pivotal role in enabling efficient and secure trading. Uniswap V3, with its innovative concentrated liquidity feature, has pushed the boundaries of what is possible in DeFi liquidity management. However, the complexities of optimizing liquidity provisioning strategies within this dynamic ecosystem require innovative solutions. Our Intelligent Liquidity Provisioning Framework represents a significant step forward in addressing these challenges. By combining agent-based modeling and reinforcement learning, we have created a powerful toolkit for liquidity providers and market participants. This framework offers a robust and adaptive solution for optimizing liquidity provisioning strategies, with a focus on maximizing utility functions that encompass fees earned, impermanent loss mitigation, and other metrics tailored to individual preferences. Resources Github: https://github.com/idrees535/Intelligent-Liquidity-Provisioning-Framework-V1 References https://kth.diva-portal.org/smash/get/diva2:1695877/FULLTEXT01.pdf https://arxiv.org/pdf/2305.15821.pdf https://github.com/KodAgge/Reinforcement-Learning-for-Market-Making/tree/main https://arxiv.org/ftp/arxiv/papers/2211/2211.01346.pdf https://arxiv.org/pdf/2004.06985.pdf https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9682687 https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0277042 https://deliverypdf.ssrn.com/delivery.php?ID=104119098102026014120072084014107007042068069003049020126088025087121115103007084028042013055035009000054122074096068089064070102052026003014069082076098016080066026088066039027093020006122067093104092065070020126069068106118079127088008098077106031120&EXT=pdf&INDEX=TRUE https://medium.com/blockapex/market-making-mechanics-and-strategies-4daf2122121c https://www.gauntlet.xyz/resources/uniswap-user-cohort-analysis https://gov.uniswap.org/t/uniswap-incentive-design-analysis/21662 https://arxiv.org/pdf/2108.07806.pdf https://www.researchgate.net/publication/341848292_Market_makers_activity_behavioural_and_agent_based_approach https://fruct.org/publications/volume-29/fruct29/files/Struc.pdf https://www.arxiv-vanity.com/papers/1911.03380/ https://insights.glassnode.com/the-week-onchain-week-31-2023/ Also published . here

A Detailed Framework for Intelligent Liquidity Provisioning in Uniswap V3 

Uniswap V3-এ বুদ্ধিমান তারল্য বিধানের জন্য একটি বিস্তারিত কাঠামো

Ein detailliertes Framework für die intelligente Liquiditätsbereitstellung in Uniswap V3

Un marco detallado para el aprovisionamiento inteligente de liquidez en Uniswap V3

Un cadre détaillé pour l'approvisionnement intelligent en liquidités dans Uniswap V3

Uniswap V3 में बुद्धिमान तरलता प्रावधान के लिए एक विस्तृत रूपरेखा

Uniswap V3 におけるインテリジェントな流動性プロビジョニングの詳細なフレームワーク

Uniswap V3의 지능형 유동성 프로비저닝을 위한 세부 프레임워크

Uma estrutura detalhada para provisionamento inteligente de liquidez no Uniswap V3

Подробная структура интеллектуального предоставления ликвидности в Uniswap V3

Uniswap V3'te Akıllı Likidite Tedariği için Ayrıntılı Bir Çerçeve

Khung chi tiết để cung cấp thanh khoản thông minh trong Uniswap V3

Uniswap V3 智能流动性配置的详细框架

General Provisions. (a)  Nothing in this order shall be construed to impair or otherwise affect: (i)   the authority granted by law to an executive department or agency, or the head thereof; or (ii)  the functions of the Director of the Office of Management and Budget relating to budgetary, administrative, or legislative proposals. (b)  This order shall be implemented consistent with applicable law and subject to the availability of appropriations. (c)  This order is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person. JOSEPH R. BIDEN JR. THE WHITE HOUSE, October 30, 2023. This content was published on October 30, 2023, on . WhiteHouse.gov

General Provisions in Biden AI Order Safeguard Executive Authority

With so many people leaving their jobs, work models shifting, and companies trying to keep and attract new employees, business leaders, and managers face the challenge of keeping their employees happy. While higher salaries and bonuses can help, they might not be enough. It's also really important to provide the best possible tools and equipment to ensure employees can work efficiently. Why? Making sure your employees have the right tools for their jobs can improve their productivity, but it's also a crucial factor in their . Also, younger employees, who are used to user-friendly experiences from video games and social media, often expect the same level of ease and efficiency from their enterprise tools. job satisfaction Equipping your employees with the right tools can benefit your company in many ways. Here are just a few of those benefits: Operational Efficiency When employees have access to the appropriate digital tools, they can work more efficiently and streamline their tasks. This leads to improved operational efficiency as processes become smoother and less time-consuming. It minimizes the need for manual workarounds and reduces errors, resulting in Operational efficiency translates into faster delivery, better service, and higher customer satisfaction. faster, more accurate results. Cost Optimization The right enterprise digital tools help optimize costs in multiple ways. By eliminating the need for investing in multiple tools and reducing interruptions or productivity losses, you can control expenses. Moreover, cost savings can be achieved by , reducing the workforce required for manual processes, and , which might incur additional costs. Cost optimization not only preserves financial well-being but also enhances an organization’s profitability. automating tasks minimizing errors Competitive Advantage With efficient enterprise tools, employees perform their tasks more effectively and with precision, resulting in an that can set businesses apart in the market. The ability to deliver better, faster, and more reliable services or products attracts and retains customers or clients. This, in turn, drives growth and ensures a competitive edge over rivals in the industry. overall improvement in service quality How can a solid enterprise solution benefit your business? The answer lies in the transformative impact it can have on KPIs. Here are 5 essential KPIs that are significantly influenced by the implementation of the right enterprise solution: Time to Completion A robust enterprise solution accelerates work processes by offering efficient tools for task management. It automates repetitive tasks, streamlines communication, and provides real-time access to crucial information. Which results in improved decision-making and, in turn, The result is faster project delivery, improved customer satisfaction, and enhanced productivity. reduced time for task completion. Time to Productivity By offering comprehensive training materials, user-friendly interfaces, and easy access to resources, new employees can quickly grasp the processes and Moreover, they can collaborate with colleagues and access essential information, tools they need to be productive. accelerating their overall productivity. Net Promoter Score Enterprise solutions boost employee satisfaction and improve how a company manages relationships with customers, making their experiences better. When employees work more efficiently, they can deliver higher-quality products or services, which keeps customers happy and likely to recommend the company to others, ultimately raising the NPS and promoting organic growth. Turnover Rate A well-implemented enterprise solution can contribute to a lower turnover rate. When employees are equipped with the right tools and have a seamless work experience, job satisfaction tends to increase. This, in turn, leads to , saving your organization the costs associated with employee attrition and recruitment. reduced turnover rates Burnout Risk Burnout risk assesses the likelihood of employees experiencing burnout due to excessive stress and workload. Enterprise solutions can mitigate that risk by optimizing workflows, automating repetitive tasks, and improving work-life balance. These tools make it easier for employees to manage their workloads and reduce stress, ultimately leading to a healthier, more sustainable work environment and a lower burnout risk. A well-designed enterprise solution can help your business thrive by improving efficiency, retaining employees, and ensuring higher customer satisfaction. So, providing your team with the right tools is an important element of a more successful and competitive future. Last thoughts The right enterprise solution serves as one of the key drivers of success. It ensures that employees are equipped with the best tools to maximize productivity, drives business growth by enhancing crucial KPIs, and ultimately keeps your company competitive in the market. According to research by Jacob Nielsen, dedicating can boost your conversion rates . So, remember to provide the right tools for your team that lead to a thriving, competitive business. 10% of your development budget to UX by 83%

How Good UX Elevates Enterprise Service Provision

Microsoft v. United States (2016) Court Filing, retrieved on July 14, 2016, is part of . You can jump to any part in this filing . This part is 15 of 22. HackerNoon’s Legal PDF Series here 1. The SCA’s Warrant Provisions The reader will recall the SCA’s provisions regarding the production of electronic communication content:  In sum, for priority stored communications, “a governmental entity may require the disclosure . . . of the contents of a wire or electronic communication . . . only pursuant to a warrant issued using the rules described in the Federal Rules of Criminal Procedure,” except (in certain cases) if notice is given to the user.  18 U.S.C. § 2703(a), (b). In our view, the most natural reading of this language in the context of the Act suggests a legislative focus on the privacy of stored communications. Warrants under § 2703 must issue under the Federal Rules of Criminal Procedure, whose Rule 41 is undergirded by the Constitution’s protections of citizens’ privacy against unlawful searches and seizures. And more generally, § 2703’s warrant language appears in a statute entitled the Electronic Communications Privacy Act, suggesting privacy as a key concern. The overall effect is the embodiment of an expectation of privacy in those communications, notwithstanding the role of service providers in their transmission and storage, and the imposition of procedural restrictions on the government’s (and other third party) access to priority stored communications. The circumstances in which the communications have been stored serve as a proxy for the intensity of the user’s privacy interests, dictating the stringency of the procedural protection they receive—in particular whether the Act’s warrant provisions, subpoena provisions, or its § 2703(d) court order provisions govern a disclosure desired by the government.   Accordingly, we think it fair to conclude based on the plain meaning of the text that the privacy of the stored communications is the “object[] of the statute’s solicitude,” and the focus of its provisions.  Morrison, 561 U.S. at 267. Continue Reading . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case No. 15–777 retrieved on September 27, 2023, from is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. cases.justia.com

The Provisions Protecting a User's Stored Communications

Efficient AKS Cluster Provisioning in a Virtual Network Using Terraform

Modesty, which may be provisionally defined as an almost instinctive fear

We introduce the — a token designed to reflect the success of the Oswap protocol and incentivize liquidity provision in Oswap pools. OSWAP token was launched in the summer of 2020 by our long-time community member Fabien (he also runs an order provider node). It was inspired by Uniswap and became the main DEX on Obyte providing easy and permissionless ability to exchange any token for any other token with always available liquidity. Oswap DEX With the launch of in the summer of 2021, trading activity significantly increased as USDC, ETH, WBTC, and other tokens bridged from Ethereum and other networks became available for trading. Counterstake Bridge In February 2022, arrived and brought leveraged trading, more income for liquidity providers, stable pairs, governance, and more. Oswap v2 The OSWAP token that becomes available today will serve two purposes: incentivize liquidity provision in selected Oswap pools like many other successful DEXes are already doing, such as Curve, Sushi, Balancer, PancakeSwap, etc; allow traders to bet on the success of the Oswap protocol by buying OSWAP token, whose appreciation rate depends on how widely it is used. To summarize briefly its tokenomics: The token will be issued on a bonding curve that allows trading OSWAP token against GBYTE and ensures always available liquidity. The price of the OSWAP token on the bonding curve gradually increases (not including other price changes, e.g. due to trading) at a rate that depends on the current Total Value Locked (TVL) of all Oswap pools. Greater TVL yields a faster appreciation rate. The price increase is achieved by gradually and automatically changing a few parameters of the bonding curve, thus moving to a slightly different bonding curve. There are continuous emissions of new OSWAP tokens (they are also achieved by changing the curve’s parameters). Half of the emissions go to liquidity providers (LPs) to incentivize liquidity provision in Oswap pools. The other half goes to stakers who lock their OSWAP tokens for some time and participate in governance. One can lock their OSWAP tokens in governance for a term between 14 days and 4 years. This also entitles the user to a share of emissions. Longer locking periods yield more voting power and a larger share of emissions. LPs deposit their LP tokens to receive a share of emissions. They can get their LP tokens back at any time. Governance decides which Oswap pools are incentivized and in what proportions. Governance can also update various parameters such as swap fee, emission rate, target appreciation rate, oracles, etc. The following sections describe the token in more detail. Bonding curve OSWAP token is issued on a bonding curve — a mathematical formula that binds the supply of the tokens to the amount of the reserve currency (GBYTE) invested in issuing them. The formula looks like this: where is the GBYTE reserve committed to issuing OSWAP tokens; r is the supply of OSWAP tokens; s 0 is the maximum supply of OSWAP tokens; s c is a coefficient that starts with 1 and changes due to accruing fees, appreciation, and emissions. The price of the OSWAP token is the derivative of with respect to : r s So, to buy OSWAP tokens, one needs to send GBYTE to an Autonomous Agent that implements the bonding curve. One can sell the tokens by sending them back to the same AA and receive GBYTE in exchange. It’s clear from the above formulas that the price grows with the growing supply, and as the supply approaches 0, both the reserve and the price go to infinity. s s This means that early investors get a lower price and every additional purchase further increases the price, while selling the token back to the curve decreases its price. Appreciation OSWAP token is designed to reflect the success of the OSWAP protocol and it’s programmed to appreciate at a rate that depends on the TVL of all Oswap pools. The initial target appreciation rate is 30% per year at the target TVL of $1m (both values can be changed by governance). If the actual TVL is different from the target TVL, the appreciation rate is scaled accordingly. For example, it would be 15% per year at $0.5m TVL. The TVL is reported by an oracle which can be changed by governance. In case new pools are added, new versions of Oswap are released, or Oswap is forked, the liquidity locked in the new pools is supposed to be included. Appreciation works by changing the parameters 0 and in such a way that the reserve and the supply remain the same while the price increases. This morphs the bonding curve, and after appreciation trading continues on the new bonding curve. s c The higher price at the current supply is not a magic increase in the wealth of OSWAP token holders. It comes at a cost — the shape of the curve changes in a way that provides worse conditions for those who redeem (sell) the tokens last. In particular, the minimum redemption price (at 0 supply) would be lower. However, this effect is offset (at least partially) by the fees accumulated from trading and added to the reserve — they morph the curve in the opposite way, thus providing better conditions for those who redeem last. Also, there are incentives to lock OSWAP tokens for a long time (see below) which make the possibility of large redemptions more remote. Appreciation is applied continuously, without any abrupt changes. The small changes to the price are calculated before every trade and are proportional to the time elapsed since the previous trade. Emissions New OSWAP tokens are continuously emitted and distributed among stakers of OSWAP tokens and liquidity providers in incentivized pools. Initially, the emissions are split between the two groups 50/50 but the shares can be changed by governance. The initial emission rate is 30% per year, and it can be changed by governance too. Unlike many other DeFi protocols that distribute their tokens to incentivize the use of the protocol, OSWAP emissions never end, and there is no risk that the protocol will be abandoned as soon as incentives end. However, governance can both increase and decrease the emission rate depending on the market conditions, in order to best serve the protocol (as the governance participants think). Like appreciation, emission works by gradually changing the 0 and parameters of the curve while keeping the reserve and the price unchanged. Like appreciation, emission comes at the cost of worsening the redemption conditions for late redeemers. Like in appreciation, this effect is offset, partially or fully, by the accumulation of trading fees. Plus, there are incentives to lock OSWAP tokens for a long time, which make the possibility of redemptions more remote. s c Emissions directed at stakers are distributed among them in proportion to their voting power (see below), which favors those who lock for a long time. Emissions directed at LPs are split among multiple pools. Which pools are eligible, and what shares they receive, is decided by governance. Each governance participant indicates their preferred shares for each pool, and their votes are weighted and averaged. The weight of each voter is equal to their voting power, which depends on their locking period and locked balance. Governance, locking, and voting power As already mentioned above, many things are decided by governance. To participate in governance, OSWAP token holders lock them for a certain time. They cannot sell the tokens until the locking period ends, and they do not receive any liquid tokens in exchange. This makes them interested in the long-term success of the token and ensures that they feel the long-term consequences of their decisions. For their participation in governance, they are rewarded with emissions of OSWAP tokens. Both the weight of their votes and the share of emissions they receive depend on their (VP). The voting power is determined by the locked balance and the time left until the lock expires. If a user locks for the maximum locking period — 4 years — they get the maximum voting power, which is equal to their locked balance. Then, their VP starts decaying exponentially, so that it is halved every half a year, or decays 4 times every year. So, it will be ½ of the balance after half a year, ¼ after a year, and 1/256 after 4 years. voting power To prevent the decay of one’s VP (and the share of emissions), one needs to extend the locking period. By constantly pushing the unlock date to 4 years from now, one can always have the maximum VP available with their balance. Re-staking (compounding) the received emissions helps to further increase the VP and get a bigger share of future emissions. If a user locks their OSWAP tokens for a period shorter than 4 years, their initial VP is calculated such that on the unlock date, it would be equal to 1/256th of the user’s balance. As a result, the VP would be lower than when locking for 4 years. The idea of voting power being dependent on the locking period was inspired by CRV and its veCRV (vote-escrowed CRV) token. The share of emissions a user receives is equal to the user’s VP divided by the total VP of all users. Farming Liquidity providers can deposit their LP tokens to receive a share of the emissions of OSWAP tokens. This might significantly increase the APY of liquidity provision and attract liquidity to the incentivized pools, which is especially important for newly launched tokens. LPs can harvest their rewards as often as they like. Once harvested, they can do one of three things: sell the received OSWAP tokens to the curve, just hold them (anticipating appreciation), lock them in governance to receive more emissions as stakers and maybe vote for redirecting more emissions to their favorite pools. LPs can of course withdraw their LP tokens at any time (and stop receiving emissions). They are not time-locked, unlike the staked OSWAP tokens. Distribution of rewards among pools As said above, it’s decided by governance. Every governance participant sets their preferred distribution, e.g. one voter could allocate 20% of their voting power to pool1, 30% to pool2, and 50% to pool3, while another voter votes for 40% to pool2, 30% to pool3, 20% to pool4, and 10% to pool5. For every pool, the total VP it receives from all voters determines its share in OSWAP emissions. Even if only one voter voted for a specific pool, it still receives a share of emissions. Since new token projects are interested in creating liquid markets for their tokens, one way to achieve this is by acquiring OSWAP tokens, locking them in governance for the maximum term, and allocating one’s VP to the pools where the new token can be traded. Assuming competition among projects for a larger share of emissions, we can expect additional demand for OSWAP tokens. This is something that supported the price of the CRV token in the . “Curve Wars” Grants to a management team The price of the OSWAP token depends on the adoption of the Oswap protocol. If the growth is too slow, additional efforts might be required to promote the protocol and develop new versions. To fund this work, OSWAP governance participants can decide to pay a portion of the bonding curve’s reserves to a team that commits to promoting and developing the protocol. It works like this: A potential team drafts a grant proposal. In the proposal, they detail who they are, their track record, what they are going to do, what they expect, the term of engagement (e.g. 6 months), and how much money they need to do the work. They compute a hash of the proposal document and submit it to OSWAP AA to create a formal proposal. Governance participants vote for or against the proposal with their VP. If it gains the majority of VP, it is accepted, and the money is paid to the team. Instead of sending the whole amount to the team, it can be sent to an intermediary AA that would release the funds in parts, based on milestones achieved. Completion of milestones can be signaled by some supervisory board that is independent of the team. The team periodically updates the community about its progress (off-chain). At the end of the engagement term, the team publishes its final report about the work done. Then, the same team can submit another proposal to be hired for the next term. Another team can compete to be chosen instead. When the funds are paid out to the team, the reserve that backs the bonding curve decreases, and the curve’s parameters 0 and are updated to keep the supply and the price unchanged. The new curve would provide worse conditions to late redeemers (similar to what happens as a result of appreciation and emission). By accepting the grant, the governance members expect this downside to be outweighed by the benefits that the team’s work brings. s c Initial sale OSWAP token will launch on April 6, 2023 at 04:34 UTC. Before this date, potential buyers can deposit their GBYTE to participate in the initial sale. On the launch date, all GBYTEs collected from buyers will be sent to the bonding curve to buy OSWAP tokens. The price will be determined by the bonding curve and it depends on the amount of GBYTEs raised in the initial sale. The initial price on the bonding curve is 1 GBYTE per 1 OSWAP token but it grows with the growing buying amount. Larger total amount — larger price. Then, buyers will be able to claim their OSWAP tokens according to their share in the total deposited GBYTEs. All buyers get the same price — the average price of the initial purchase from the bonding curve. This price will be lower than the trading price on the curve immediately after the initial purchase (the opening price of free trading is also the final price of the initial sale). Thus, the next buyer will have to pay a higher price, and the participants of the initial sale buy with a discount relative to the opening price. However, all tokens bought in the initial sale will be locked in governance for the maximum term — 4 years. This means that: The token will have well-represented governance from day one. The initial sell pressure will be zero as the bought tokens cannot be sold for the next 4 years. And the only place where one can buy them is the bonding curve, with each purchase increasing the price on the curve. There will be a floor price as only tokens bought after the initial sale can be sold back to the curve. The initial market cap of OSWAP tokens (number of tokens multiplied by the opening price on the curve) will be higher than the amount of GBYTEs sent to buy the tokens. However, these tokens cannot be sold for the next 4 years. As investors add their deposits, it will be possible to estimate the future average buying price and the future opening price. If a user changes their mind, they can withdraw their deposit before the launch. New deposits are accepted up to 1 day before the launch (to ensure that last-minute deposits don’t raise the price above someone’s maximum acceptable price if they think that such a price exists). As a precaution, the team reserves the right to move the launch date further into the future (but it cannot accelerate the launch). This is the only privilege that the Obyte team has, and it obviously becomes irrelevant after the launch. Obyte Buying from other networks It is possible to buy OSWAP tokens (both in the initial sale and after it) from other networks. Investors can buy the tokens with USDC, ETH, and WBTC on Ethereum or with GBYTE on Ethereum, BSC, or Polygon. Users just need to connect their MetaMask wallet and send the tokens, and they will be automatically bridged through and swapped through Oswap if necessary. Users obviously need to have an in order to receive the tokens. Counterstake Bridge Obyte wallet Floor price As mentioned above, there are incentives for OSWAP holders to lock their tokens in governance for a long time in order to receive a larger share of stakers emissions and be able to direct LP emissions to their favorite pools. This effectively removes a portion of the OSWAP supply from circulation, and this part of supply cannot be sold back to the curve. This means that there is a floor price of OSWAP token, which is determined assuming all freely circulating tokens have been sold to the curve and the supply has become equal to the locked supply. The price can’t go lower in the short term. Initial sale is already open The initial sale website is at , and after April 6, 2023, 04:34 UTC it will become the website for trading the OSWAP token, staking, governance, and farming LP tokens. You can already preview some governance pages that will be available after the launch. token.oswap.io The testnet version of the OSWAP token is available at and you can use it to try all the functions that will be available on mainnet after the launch. testnet-token.oswap.io OSWAP token is the first token issued on a bonding curve of this kind, and with a combination of ample initial liquidity provided by the bonding curve and strong locking incentives, we hope that it will help attract liquidity to Oswap pools and prove to be a valuable asset for its holders. Also published . here

OSWAP Token: Incentivizing Liquidity Provision in Oswap Pools

Token OSWAP: incentivando la provisión de liquidez en los pools de Oswap

Jeton OSWAP : incitation à la fourniture de liquidités dans les pools Oswap

OSWAP टोकन: Oswap पूल में चलनिधि प्रावधान को प्रोत्साहन देना

OSWAP トークン: Oswap プールでの流動性提供のインセンティブ

Token OSWAP: Incentivando a provisão de liquidez em pools Oswap

OSWAP Token: Khuyến khích cung cấp thanh khoản trong Oswap Pools

OSWAP 代币：激励 Oswap 池中的流动性供应

Advancements for Digital Wallet Developers Digital wallets and tokenization have been popular among FinTechs and developers for several years. However, the process of adding a payment card to a digital wallet has been a point of friction for the user experience. The good news is there is a new solution called “Web Push Provisioning” (WPP) that may be a gamechanger in the industry. In partnership with the digital wallet providers, this technology was recently brought to market by Marqeta, an fintech leader in payments and tokenization. In this article, we will discuss what web push provisioning is, how it differs from current tokenization methods, and its potential impact on FinTechs, developers, and consumers. We’ll also consider some typical use cases for web push provisioning. Before diving in, let’s cover some background concepts. Digital Wallets and Tokenization: An Overview Digital wallets are virtual storage spaces for payment information—such as credit or debit card information—that can be used to make online or contactless payments. Think about Apple Pay or Google Wallet. Tokenization is the process of replacing sensitive payment information—like a credit card number—with a unique, random string of characters called a that can be used to represent the payment information in a secure way. Tokenization allows for the safe storage of payment cards in a digital wallet, enabling online or contactless payments without exposing any sensitive information. token Up until recently, there were to add a payment card to a digital wallet: three main ways Manual entry In-app provisioning Card-on-file involves the user manually entering or taking a photo of the payment card information and adding it to their digital wallet app. This provisioning method is employed when users already possess the physical cards they want to insert into their digital wallets. Manual entry ( ) Provisioning via Manual Entry source involves the user installing or opening an app from a bank or merchant and then using the custom app to provision a virtual card, which is then added to the user's digital wallet. In-app provisioning ( ) In-App Provisioning source involves the user already having a payment card added to their digital wallet but then adding it for use on a different device. Card-on-file An Alternative: Web Push Provisioning (WPP) WPP is a new method for tokenizing a payment card and adding it to a digital wallet. This means that users can immediately access funds from their payment card through their digital wallet without installing or opening a separate app. WPP offers a convenient and streamlined way for users to add payment cards to their digital wallets and access their funds. WPP allows users to provision a virtual card and add it to their digital wallet from within a web browser, eliminating the need for a custom mobile application. What does this mean for developers and consumers? WPP is different from both manual entry and in-app provisioning in several ways. With provisioning via manual entry, the user must work within the digital wallet app and manually enter their payment card information or take a photo of the card. However, with WPP, the user does not need to work within their digital wallet app and can instead . scan a QR code or click on a link to add their payment card to their digital wallet WPP is also different from in-app provisioning, meaning the user does not need to download, install, and open a custom application just to add a card from that provider to their digital wallet. This also means that , and . Instead, WPP allows developers to build for the browser, reducing both the development time and the friction of the user experience. the provider does not need to develop a mobile application the user is not required to work within the mobile app environment Use Cases for Web Push Provisioning WPP allows companies to leverage QR codes, links, and text messages to quickly and easily enable users to add payment cards to their digital wallets. By using WPP, users are taken to a web page that creates a virtual card with available funds and prompts them to add it to their digital wallet for immediate use. Ultimately, the result is a smoother user experience for adding a payment card to a digital wallet. WPP can be used in a variety of contexts, such as , , and . Businesses no longer need to entice their customers by saying, “ .” Instead, a store can use WPP to sign up customers for a promotion by sending a text message with a link to complete the WPP process (which doesn’t involve an app). store promotions business cards with QR codes for events email campaigns Download our app, and we'll give you $10 for your next purchase Similarly, business cards with QR codes can be handed out at promotional events, allowing customers to scan the QR code and complete the WPP process through a web page. Links to WPP completion can also be embedded in emails as a convenient way for users to add payment cards to their digital wallets. Conclusion WPP is a new method for tokenizing payment cards and adding them to digital wallets. It allows users to add payment cards to their digital wallets from within a web browser, eliminating the need for a custom mobile application. For the end user, this means having immediate access to funds from their payment cards through their digital wallets without the need to install or open a separate app. WPP simplifies key elements of what companies need to do in order to get consumers to add payment cards to their digital wallets. Through QR codes, links, and text messages, consumers can add payment cards to their digital wallets, reducing friction in this user flow while allowing developers to build card provisioning right into the browser. Using Marqeta’s on tokenization, you can begin building simple solutions for adding cards to digital wallets. With a growing set of innovative use cases, WPP will open doors for your FinTech to be on the cutting edge of tomorrow’s digital wallet trends. Also consider joining me in this on Web Push Provisioning and how Branch is building innovative banking experiences for leading tech brands. documentation upcoming webinar

How Web Push Provisioning Can Be Used

Darwinism, Stated by Darwin himself, is part of the HackerNoon Books Series. You can jump to any chapter in this book here . THE PROVISIONAL HYPOTHESIS OF PANGENESIS THE PROVISIONAL HYPOTHESIS OF PANGENESIS. Every one would wish to explain to himself, even in an imperfect manner, how it is possible for a character possessed by some remote ancestor suddenly to reappear in the offspring; how the effects of increased or decreased use of a limb can be transmitted to the child; how the male sexual element can act not solely on the ovules, but occasionally on the mother-form; how a hybrid can be produced by the union of the cellular tissue of two plants independently of the organs of generation; how a limb can be reproduced on the exact line of amputation, with neither too much nor too little added; how the same organism may be produced by such widely different processes as budding and true seminal generation; and, lastly, how, of two allied forms, one passes in the course of its development through the most complex metamorphoses, and the other does not do so, though when mature both are alike in every detail of structure. I am aware that my view is merely a provisional hypothesis or speculation; but, until a better one be advanced, it will serve to bring together a multitude of facts which are at present left disconnected by any efficient cause. As Whewell, the historian of the inductive sciences, remarks, “Hypotheses may often be of service to science when they involve a certain portion of incompleteness, and even of error.” Under this point of view I venture to advance the hypothesis of pangenesis, which implies that every separate part of the whole organization reproduces itself. So that ovules, spermatozoa, and pollen-grains—the fertilized egg or seed, as well as buds—include and consist of a multitude of germs thrown off from each separate part or unit. FUNCTIONAL INDEPENDENCE OF THE UNITS OF THE BODY. Physiologists agree that the whole organism consists of a multitude of elemental parts, which are to a great extent independent of one another. Each organ, says Claude Bernard, has its proper life, its autonomy; it can develop and reproduce itself independently of the adjoining tissues. A great German authority, Virchow, asserts still more emphatically that each system consists of an “enormous mass of minute centers of action.... Every element has its own special action, and, even though it derive its stimulus to activity from other parts, yet alone effects the actual performance of duties.... Every single epithelial and muscular fiber-cell leads a sort of parasitical existence in relation to the rest of the body.... Every single bone-corpuscle really possesses conditions of nutrition peculiar to itself.” Each element, as Sir J. Paget remarks, lives its appointed time and then dies, and is replaced after being cast off or absorbed. I presume that no physiologist doubts that, for instance, each bone-corpuscle of the finger differs from the corresponding corpuscle in the corresponding joint of the toe; and there can hardly be a doubt that even those on the corresponding sides of the body differ, though almost identical in nature. This near approach to identity is curiously shown in many diseases in which the same exact points on the right and left sides of the body are similarly affected; thus Sir J. Paget gives a drawing of a diseased pelvis, in which the bone has grown into a most complicated pattern, but “there is not one spot or line on one side which is not represented, as exactly as it would be in a mirror, on the other.” Many facts support this view of the independent life of each minute element of the body. Virchow insists that a single bone-corpuscle or a single cell in the skin may become diseased. The spur of a cock, after being inserted into the ear of an ox, lived for eight years, and acquired a weight of three hundred and ninety-six grammes (nearly fourteen ounces) and the astonishing length of twenty-four centimetres, or about nine inches; so that the head of the ox appeared to bear three horns. The tail of a pig has been grafted into the middle of its back, and reacquired sensibility. Dr. Ollier inserted a piece of periosteum from the bone of a young dog under the skin of a rabbit, and true bone was developed. A multitude of similar facts could be given. * * * * * What can be more wonderful than that characters, which have disappeared during scores, or hundreds, or even thousands of generations, should suddenly reappear perfectly developed, as in the case of pigeons and fowls, both when purely bred and especially when crossed; or as with the zebrine stripes on dun-colored horses, and other such cases? Many monstrosities come under this same head, as when rudimentary organs are redeveloped, or when an organ which we must believe was possessed by an early progenitor of the species, but of which not even a rudiment is left, suddenly reappears, as with the fifth stamen in some Scrophulariaceæ. * * * * * In every living creature we may feel assured that a host of long-lost characters lie ready to be evolved under proper conditions. How can we make intelligible, and connect with other facts, this wonderful and common capacity of reversion—this power of calling back to life long-lost characters? * * * * * Imperfect nails sometimes appear on the stumps of the amputated fingers of man; and it is an interesting fact that with the snake-like saurians, which present a series with more and more imperfect limbs, the terminations of the phalanges first disappear, “the nails becoming transferred to their proximal remnants, or even to parts which are not phalanges.” * * * * * Mr. Salter and Dr. Maxwell Masters have found pollen within the ovules of the passion-flower and of the rose. Buds may be developed in the most unnatural positions, as on the petal of a flower. Numerous analogous facts could be given. I do not know how physiologists look at such facts as the foregoing. According to the doctrine of pangenesis, the gemmules of the transposed organs become developed in the wrong place, from uniting with wrong cells or aggregates of cells during their nascent state; and this would follow from a slight modification in their elective affinities. * * * * * On any ordinary view it is unintelligible how changed conditions, whether acting on the embryo, the young or the adult, can cause inherited modifications. It is equally or even more unintelligible, on any ordinary view, how the effects of the long-continued use or disuse of a part, or of changed habits of body or mind, can be inherited. A more perplexing problem can hardly be proposed; but on our view we have only to suppose that certain cells become at last structurally modified, and that these throw off similarly modified gemmules. This may occur at any period of development, and the modification will be inherited at a corresponding period; for the modified gemmules will unite in all ordinary cases with the proper preceding cells, and will consequently be developed at the same period at which the modification first arose. With respect to mental habits or instincts, we are so profoundly ignorant of the relation between the brain and the power of thought that we do not know positively whether a fixed habit induces any change in the nervous system, though this seems highly probable; but, when such habit or other mental attribute, or insanity, is inherited, we must believe that some actual modification is transmitted; and this implies, according to our hypothesis, that gemmules derived from modified nerve-cells are transmitted to the offspring. NECESSARY ASSUMPTIONS. I have now enumerated the chief facts which every one would desire to see connected by some intelligible bond. This can be done, if we make the following assumptions, and much may be advanced in favor of the chief one. The secondary assumptions can likewise be supported by various physiological considerations. It is universally admitted that the cells or units of the body increase by self-division or proliferation, retaining the same nature, and that they ultimately become converted into the various tissues and substances of the body. But besides this means of increase I assume that the units throw off minute granules which are dispersed throughout the whole system; that these, when supplied with proper nutriment, multiply by self-division, and are ultimately developed into units like those from which they were originally derived. These granules may be called gemmules. They are collected from all parts of the system to constitute the sexual elements, and their development in the next generation forms a new being; but they are likewise capable of transmission in a dormant state to future generations and may then be developed. Their development depends on their union with other partially developed, or nascent cells which precede them in the regular course of growth. Why I use the term union will be seen when we discuss the direct action of pollen on the tissues of the mother-plant. Gemmules are supposed to be thrown off by every unit, not only during the adult state, but during each stage of development of every organism; but not necessarily during the continued existence of the same unit. Lastly, I assume that the gemmules in their dormant state have a mutual affinity for each other, leading to their aggregation into buds or into the sexual elements. Hence, it is not the reproductive organs or buds which generate new organisms, but the units of which each individual is composed. These assumptions constitute the provisional hypothesis which I have called pangenesis. * * * * * But I have further to assume that the gemmules in their undeveloped state are capable of largely multiplying themselves by self-division, like independent organisms. Delpino insists that to “admit of multiplication by fissiparity in corpuscles, analogous to seeds or buds ... is repugnant to all analogy.” But this seems a strange objection, as Thuret has seen the zoöspore of an alga divide itself, and each half germinated. Haeckel divided the segmented ovum of a siphonophora into many pieces, and these were developed. Nor does the extreme minuteness of the gemmules, which can hardly differ much in nature from the lowest and simplest organisms, render it improbable that they should grow and multiply. A great authority, Dr. Beale, says that “minute yeast-cells are capable of throwing off buds or gemmules, much less than the 1/100000 of an inch in diameter”; and these he thinks are “capable of subdivision practically ad infinitum.” A particle of small-pox matter, so minute as to be borne by the wind, must multiply itself many thousandfold in a person thus inoculated; and so with the contagious matter of scarlet fever. It has recently been ascertained that a minute portion of the mucous discharge from an animal affected with rinderpest, if placed in the blood of a healthy ox, increases so fast that in a short space of time “the whole mass of blood, weighing many pounds, is infected, and every small particle of that blood contains enough poison to give, within less than forty-eight hours, the disease to another animal.” * * * * * The gemmules derived from each part or organ must be thoroughly dispersed throughout the whole system. We know, for instance, that even a minute fragment of a leaf of a begonia will reproduce the whole plant; and that if a fresh-water worm is chopped into small pieces, each will reproduce the whole animal. Considering also the minuteness of the gemmules and the permeability of all organic tissues, the thorough dispersion of the gemmules is not surprising. That matter may be readily transferred without the aid of vessels from part to part of the body, we have a good instance in a case recorded by Sir J. Paget of a lady, whose hair lost its color at each successive attack of neuralgia and recovered it again in the course of a few days. With plants, however, and probably with compound animals, such as corals, the gemmules do not ordinarily spread from bud to bud, but are confined to the parts developed from each separate bud; and of this fact no explanation can be given. TWO OBJECTIONS ANSWERED. But we have here to encounter two objections which apply not only to the regrowth of a part, or of a bisected individual, but to fissiparous generation and budding. The first objection is that the part which is reproduced is in the same stage of development as that of the being which has been operated on or bisected; and in the case of buds, that the new beings thus produced are in the same stage as that of the budding parent. Thus a mature salamander, of which the tail has been cut off, does not reproduce a larval tail; and a crab does not reproduce a larval leg. In the case of budding it was shown in the first part of this chapter that the new being thus produced does not retrograde in development—that is, does not pass through those earlier stages which the fertilized germ has to pass through. Nevertheless, the organisms operated on or multiplying themselves by buds must, by our hypothesis, include innumerable gemmules derived from every part or unit of the earlier stages of development; and why do not such gemmules reproduce the amputated part or the whole body at a corresponding early stage of development? The second objection, which has been insisted on by Delpino, is that the tissues, for instance, of a mature salamander or crab, of which a limb has been removed, are already differentiated and have passed through their whole course of development; and how can such tissues in accordance with our hypothesis attract and combine with the gemmules of the part which is to be reproduced? In answer to these two objections we must bear in mind the evidence which has been advanced, showing that at least in a large number of cases the power of regrowth is a localized faculty, acquired for the sake of repairing special injuries to which each particular creature is liable; and, in the case of buds or fissiparous generation, for the sake of quickly multiplying the organism at a period of life when it can be supported in large numbers. These considerations lead us to believe that in all such cases a stock of nascent cells or of partially developed gemmules are retained for this special purpose either locally or throughout the body, ready to combine with the gemmules derived from the cells which come next in due succession. If this be admitted, we have a sufficient answer to the above two objections. Anyhow, pangenesis seems to throw a considerable amount of light on the wonderful power of regrowth. EFFECT OF MORBID ACTION. We have as yet spoken only of the removal of parts, when not followed by morbid action: but, when the operation is thus followed, it is certain that the deficiency is sometimes inherited. In a former chapter instances were given, as of a cow, the loss of whose horn was followed by suppuration, and her calves were destitute of a horn on the same side of their heads. But the evidence which admits of no doubt is that given by Brown-Séquard with respect to Guinea-pigs, which, after their sciatic nerves had been divided, gnawed off their own gangrenous toes, and the toes of their offspring were deficient in at least thirteen instances on the corresponding feet. The inheritance of the lost part in several of these cases is all the more remarkable as only one parent was affected; but we know that a congenital deficiency is often transmitted from one parent alone—for instance, the offspring of hornless cattle of either sex, when crossed with perfect animals, are often hornless. How, then, in accordance with our hypothesis can we account for mutilations being sometimes strongly inherited, if they are followed by diseased action? The answer probably is that all the gemmules of the mutilated or amputated part are gradually attracted to the diseased surface during the reparative process, and are there destroyed by the morbid action. TRANSMISSION LIMITED. The transmission of dormant gemmules during many successive generations is hardly in itself more improbable, as previously remarked, than the retention during many ages of rudimentary organs, or even only of a tendency to the production of a rudiment; but there is no reason to suppose that dormant gemmules can be transmitted and propagated forever. Excessively minute and numerous as they are believed to be, an infinite number, derived, during a long course of modification and descent, from each unit of each progenitor, could not be supported or nourished by the organism. But it does not seem improbable that certain gemmules, under favorable conditions, should be retained and go on multiplying for a much longer period than others. Finally, on the view here given, we certainly gain some insight into the wonderful fact that the child may depart from the type of both its parents, and resemble its grandparents, or ancestors removed by many hundreds of generations. * * * * * The child, strictly speaking, does not grow into the man, but includes germs which slowly and successively become developed and form the man. In the child, as well as in the adult, each part generates the same part. Inheritance must be looked at as merely a form of growth, like the self-division of a lowly-organized unicellular organism. Reversion depends on the transmission from the forefather to his descendants of dormant gemmules, which occasionally become developed under certain known or unknown conditions. Each animal and plant may be compared with a bed of soil full of seeds, some of which soon germinate, some lie dormant for a period, while others perish. When we hear it said that a man carries in his constitution the seeds of an inherited disease, there is much truth in the expression. No other attempt, as far as I am aware, has been made, imperfect as this confessedly is, to connect under one point of view these several grand classes of facts. An organic being is a microcosm—a little universe, formed of a host of self-propagating organisms, inconceivably minute and numerous as the stars in heaven. 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. Charles Darwin (2022). Darwinism Stated by Darwin himself. Urbana, Illinois: Project Gutenberg. Retrieved October 2022, from https://www.gutenberg.org/cache/epub/69147/pg69147-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 PROVISIONAL HYPOTHESIS OF PANGENESIS

In this article, we are going to learn how to automate the provisioning of cloud resources via Crossplane and combine it with GitOps practices. You will benefit most from this blog if you are a Platform or DevOps Engineer, Infrastructure Architect or Operations Specialist. If you are new to GitOps, read more about it in my blog GitOps with Kubernetes Let’s set the stage by imagining the following context. We are working as a part of a Platform Team in a large organization. Our goal is to help Development Teams to onboard get up to speed with using our Cloud Infrastructure. Here are a few base requirements: Platform Team doesn’t have resources to deal with every request individually, so there must be a very high degree of automation Company policy is to adopt the . We should expose the cloud resources only when needed with the lowest permissions necessary. principle of least privilege Developers are not interested in managing the cloud, they should only without even needing to login to a cloud console. consume cloud resources New Teams should get set of cloud resources for when on-boarding to the Platform. their own self-managing It should be to provision new cloud resources . easy on demand Initial Architecture The requirements lead us to an initial architecture proposal with the following high-level solution strategy. create template repositories for various types of workloads (using would be helpful) Backstage Software Templates once a new Team is onboarded and creates the first repository from a template, it will trigger a CI pipeline and deploy common infrastructure components by adding the repository as Source to Flux infrastructure repo once a Team wants to create more cloud infrastructure, they can place the Crossplane claim YAMLs in the designated folder in their repository adjustments to this process are easily implemented using Crossplane Compositions In real world scenario we would manage Crossplane also using Flux, but for demo purposes we are focusing only on the application level. The developer experience should be similar to this: Tools and Implementation Knowing the requirements and initial architecture, we can start selecting the tools. For our example, the tools we will use are and . Flux Crossplane We are going to use Flux as a GitOps engine, but the same could be achieved with ArgoCD or Rancher Fleet. Let’s look at the architecture and use cases that both tools support. Flux Architecture Overview Flux exposes several components in the form of Kubernetes CRDs and controllers that help with expressing a workflow with the GitOps model. Short description of 3 major components. All those components have their corresponding CRDs. main role is to provide a standardized API to manage sources of the Kubernetes deployments; Git and Helm repositories. ’s Source Controller apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 1m
  url: https://github.com/stefanprodan/podinfo is a CD part of the workflow. Where source controllers specify sources for data, this controller specifies what artefacts to run from a repository. Kustomize Controller apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: webapp
  namespace: apps
spec:
  interval: 5m
  path: "./deploy"
  sourceRef:
    kind: GitRepository
    name: webapp
    namespace: shared This controller can work with kustomization files, but also plain Kubernetes manifests This operator helps manage Helm chart releases containing Kubernetes manifests and deploy them onto a cluster. Helm Controller apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: backend
  namespace: default
spec:
  interval: 5m
  chart:
    spec:
      chart: podinfo
      version: ">=4.0.0 <5.0.0"
      sourceRef:
        kind: HelmRepository
        name: podinfo
        namespace: default
      interval: 1m
  upgrade:
    remediation:
      remediateLastFailure: true
  test:
    enable: true
  values:
    service:
      grpcService: backend
    resources:
      requests:
        cpu: 100m
        memory: 64Mi Crossplane Architecture Overview Let’s look at what the Crossplane component model looks like. A word of warning, if you are new to Kubernetes this might be overwhelming, but there is value in making an effort to understand it. The below diagram shows the Crossplane component model and its basic interactions. Source: Author based on Crossplane.io Learn more about Crossplane in my blog “ ” Infrastructure as Code: the next big shift is here Demo: Using Flux and Crossplane If you want to follow along with the demo, clone , it contains all the scripts to run the demo code. this repository Prerequisites In this demo, we are going to show how to use Flux and Crossplane to provision an EC2 instance directly from a new GitHub repository. This simulates a new team onboarding to our Platform. To follow along, you will need AWS CLI configured on your local machine. Once you obtain credentials, configure default profile for AWS CLI following . this tutorial Locally installed you will need: Docker Desktop or other container run time WSL2 if using Windows kubectl Run in the root folder of the project, this will: make If you are running on on Mac, use make setup_mac instead of make . Install (Kubernetes IN Docker) if not already installed kind Create KIND cluster called crossplane-cluster and swap context to it Install crossplane using helm Install crossplane CLI if not already installed Install flux CLI if not already installed Install AWS provider on the cluster Create a temporary file with AWS credentials based on the default CLI profile Create a secret with AWS credentials in the crossplane-system namespace Configure AWS provider to use the secret for provisioning the infrastructure Remove the temporary file with credentials so it’s not accidentally checked in the repository Following tools need to be installed manually GitHub CLI gh IMPORTANT: The demo code will create a small EC2 Instance in eu-centra-1 region. The instance and underlying infrastructure will be removed as part of the demo, but please make sure all the resources were successfully removed and in case of any disruptions in the demo flow, be ready to remove the resources manually. Setup Flux Repository create a new KIND cluster with , this will install Crossplane with AWS provider and configure secret to access selected AWS account make Flux CLI was installed as put of the Makefile scrip, but optionally you can configure shell completion for the CLI . <(flux completion zsh) Refer to the page for more installation options Flux documentation create an in GitHub with full repo permissions. access token export variables for your GitHub user and the newly created token export GITHUB_TOKEN=<token copied form GitHub> export GITHUB_USER=<your user name> use flux to bootstrap a new GitHub repository so flux can manage itself and underlying infrastructure Flux will look for GITHUB_USER and GITHUB_TOKEN variables and once found will create a private repository on GitHub where Flux infrastructure will be tracked. flux bootstrap github  \
        --owner=${GITHUB_USER} \
        --repository=flux-infra \
        --path=clusters/crossplane-cluster  \
        --personal Setup Crossplane EC2 Composition Now we will install a that defines what cloud resources to crate when someone asks for an EC2 claim. Crossplane Composition setup Crossplane composition and definition for creating EC2 instances kubectl crossplane install configuration piotrzan/crossplane-ec2-instance:v1 fork repository with the EC2 claims and answer YES when prompted whether to clone the repository gh repo fork https://github.com/Piotr1215/crossplane-ec2 Clone Flux Infra Repository clone the flux infra repository created in your personal repos git clone git@github.com:${GITHUB_USER}/flux-infra.git cd flux-infra Add Source add source repository to tell Flux what to observe and synchronize Flux will register this repository and every 30 seconds check for changes. execute below command in the flux-infra repository, it will add a Git Source flux create source git crossplane-demo \
   --url=https://github.com/${GITHUB_USER}/crossplane-ec2.git \
   --branch=master \
   --interval=30s \
   --export > clusters/crossplane-cluster/demo-source.yaml the previous command created a file in clusters/crossplane-cluster subfolder, commit the file git add . git commit -m "Adding Source Repository" git push execute to see active Git Repositories sources in Flux kubectl get gitrepositories.source.toolkit.fluxcd.io -A Create Flux Kustomization setup watch on the AWS managed resources, for now, there should be none watch kubectl get managed create Flux Kustomization to watch for a specific folder in the repository with the Crossplane EC2 claim flux create kustomization crossplane-demo \
  --target-namespace=default \
  --source=crossplane-demo \
  --path="./ec2-claim" \
  --prune=true \
  --interval=1m \
  --export > clusters/crossplane-cluster/crossplane-demo.yaml git add . git commit -m "Adding EC2 Instance" git push after a minute or so you should see a new EC2 Instance being synchronized with Crossplane and resources in AWS Recap: Provisioning GitOps Cloud Infrastructure Let’s take a step back and make sure we understand all the resources and repositories used. The first repository we have created is what Flux uses to manage itself on the cluster as well as other repositories. To tell Flux about a repository with Crossplane EC2 claims, we have created a YAML file that points to HTTPS address of the repository with the EC2 claims. GitSource The EC2 claims repository contains a folder where plain Kubernetes manifest files are located. To tell Flux what files to observe, we have created a and linked it with via its name. points to the folder containing K8s manifests. Kustomization GitSource Kustomization Cleanup to clean up the EC2 Instance and underlying infrastructure, remove the claim-aws.yaml demo from the crossplane-ec2 repository rm ec2-claim/claim-aws.yaml git add . git commit -m "EC2 instance removed" after a commit or timer lapse Flux will synchronize and Crossplane will pick up the removed artefact and delete cloud resources the ec2-claim folder must be present in the repo after the claim yaml is removed, otherwise Flux cannot reconcile Manual Cleanup In case you cannot use the repository, it’s possible to cleanup the resources by deleting them from flux. deleting Flux kustomization will remove all the resources from the cluster and AWS flux delete kustomization crossplane-demo to clean up the EC2 Instance and underlying infrastructure, remove the ec2 claim from the cluster kubectl delete VirtualMachineInstance sample-ec2 Cluster Cleanup wait until the output doesn't contain any AWS resources watch kubectl get managed delete the cluster with make cleanup optionally remove the repository flux-infra Summary: GitOps Cloud Infrastructure GitOps with Flux or Argo CD and Crossplane offers a very powerful and flexible model for Platform builders. In this demo, we have focused on the applications side with Kubernetes clusters deployed some other way, either with Crossplane or Fleet or Cluster API etc. What we achieved on top of using Crossplane’s Resource Model is the fact that we do not interact with kubectl directly any longer to manage resources, but rather delegate this activity to Flux. Crossplane still runs on the cluster and reconciles all resources. In other words, we’ve moved the API surface from kubectl to Git. This article was also published here

GitOps Tutorial: How to Provision an EC2 Instance with Crossplane and Flux

Using Bicep, we can deploy and manage all the resources required for our Azure Container Apps. In this post, we'll write a Bicep template that defines all the infrastructure required for our Container App and deploys it using the AZ CLI. In our Bicep template, we'll be deploying the following resources: A Log Analytics workspace. Azure Container Registry An Azure Container App Environment A Container App. Before we kick this off, it's to note that Container Apps is ! That means what I publish in my present might/will change in your future! One example of this is that the namespace that Container Apps currently reside in will be changing in March 2022, as referenced in ( ) REALLY IMPORTANT currently in preview this GitHub issue Note to self, update this article! Creating our Container App resources in Bicep Bicep is a domain-specific language that we can use as Infrastructure as Code (IaC) that Microsoft created to deploy Azure resources. Bicep code is compiled to ARM templates and in my opinion, is a lot nicer to work with than ARM. To work with Bicep, there's a fantastic that we can use to work with Bicep. Open up Visual Studio Code and click the tab. Enter into the search bar and you should see the extension. Visual Studio Code extension extensions Bicep To work with Bicep, you'll also need to have Azure CLI version 2.20.0 or later. Check out for more details on how to get Bicep set up on your machine. this page Now that we have everything set up, we can start writing our Bicep templates with all the resources we need for our Container Apps. Log Analytics Container Apps gathers data about your container app and stores it in Log Analytics. We can write single text strings or a line of serialized JSON data to Log Analytics. For our Container App, we'll need to create a Log Analytics workspace to send our Container Apps logs to. @description('Name of the log analytics workspace')
param logAnalyticsName string

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2021-12-01-preview' = {
  name: logAnalyticsName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
} In this resource block, we're creating our Log Analytics workspace, providing it with the name of the workspace using a parameter, a location (which I'll discuss in a bit) and the SKU defined in the properties block. Azure Container Registry Next up we will need to create an Azure Container Registry. In future posts, I'll show you how we can pull images from our container registry and deploy it to a Container App. But for now, we can create our Container Registry in Bicep like so: @description('Name of the connected Container Registry')
param containerRegistryName string

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-12-01-preview' = {
  name: containerRegistryName
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
} Here, I'm giving my ACR instance a name via a parameter, deploying it in the same location as my Log Analytics workspace, setting the SKU to basic, and then enabling the Admin User. Usually, we do this. Instead, we'd create a managed identity for our Container Registry and our Container App, and then assign a to our Container App of 'AcrPull' which will allow our Container App to pull images from our registry. shouldn't role At the time of writing, however, managed identities can't be created for our Container Apps, so as a workaround, we'll enable the admin user in our container registry and use the login to authorize our Container App to pull images from the registry. Azure Container App Environment Let's move onto creating an environment for our Container Apps. Individual Container Apps are deployed to a single . The environment acts as a secure boundary around groups of container apps. Container Apps environment Container Apps in the same environment are deployed to the same virtual network and they write logs to the same Log Analytics workspace. For our Bicep template, we'll define our Container App environment and configure it to send logs to our Log Analytics workspace that we've just defined. @description('Name of the Container App Environment')
param containerAppEnvName string

resource containerAppEnvironment 'Microsoft.Web/kubeEnvironments@2021-03-01' = {
  name: containerAppEnvName
  location: location 
  kind: 'containerenvironment'
  properties: {
    environmentType: 'managed'
    internalLoadBalancerEnabled: false
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalytics.properties.customerId
        sharedKey: logAnalytics.listKeys().primarySharedKey
      }
    }
  }
} Here we're providing a name for our Container Apps environment with a parameter and deploying it in the same location as our other resources. For this Container Apps environment, we are disabling the internal load balancer, because we're not working with a vNET for this environment. We can set this flag to to make this environment visible only within the vNET subnet, but that's out of scope for this article. true We set the environment type to as this is the only supported type for Container App Environments. We then configure our environment to send logs to Log Analytics with the block. Here we use the and the , which we can access as outputs of our resource. managed logAnalyticsConfiguration customerId primarySharedKey logAnalytics To see what else we can configure when creating Container App Environments in Bicep, check out the template reference . here Container App We now have an environment that we can deploy our Container Apps to, so let's write up some Bicep for a single Container App. @description('Name of the TodoApi Container App')
param todoApiContainerName string

resource todoApiContainerApp 'Microsoft.Web/containerApps@2021-03-01' = {
  name: todoApiContainerName
  location: location
  properties: {
    kubeEnvironmentId: containerAppEnvironment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 80
        allowInsecure: false
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      }
      registries: [
        {
          server: containerRegistry.name
          username: containerRegistry.properties.loginServer
          passwordSecretRef: 'container-registry-password'
        }
      ]
      secrets: [
        {
          name: 'container-registry-password'
          value: containerRegistry.listCredentials().passwords[0].value
        }
      ]
    }
    template: {
      containers: [
        {
          name: todoApiContainerName
          image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
          resources: {
            cpu: '0.5'
            memory: '1Gi'
          }         
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
} There's quite a bit happening here so let's break it down a bit: Starting with the basics, I'm giving my Container App a name that I will set as a parameter and deploying it in the same location as the rest of my resources. We then move onto our Container App-specific properties. We need to provide the resource ID of the Container App's kubeEnvironment to tell our Bicep code that this Container App belongs to our Container App environment. We do this by accessing the ID as an output of our resource. containerAppEnvironment Within our block, we're enabling external Ingress and setting our target port for this Container to port 80. We deny insecure traffic and set the traffic level to our latest revision at 100%. If we had , we split traffic between our revisions. Since we're only working with one revision, we'll send all traffic there. configuration multiple revisions Next up, we define the registry that our container app will pull images from. We do this by providing the server name and username as outputs from our resource block that we defined earlier. We then provide a to the name of the secret that we will use to store the login password for our Azure Container Registry. containerRegistry reference We then define a block that will create our secret that has a value containing the password needed to access our Azure Container Registry. Again, we use the output from our to get this password. secret containerRegistry In our block, we define the container that we'll deploy to our Container App. In my array, I'm using the same name as my container app for my image, using a simple hello-world image that Microsoft has provided and setting both CPU and Memory resources (You can read how to configure your containers in Container Apps ). Within my block, I'm just setting the minimum and the maximum number of replicas to 1, but at the time of writing, we could set a . template container here scale maximum of up to 25 replicas For more information on what we can define in a Container Apps Bicep template, check out the template guide . here Deploying our Bicep Template Our full Bicep template should look like this (I've moved things around just to tidy it up a bit, so feel free to copy and paste this if you want, or fix your template to make it look similar): @description('Name of the log analytics workspace')
param logAnalyticsName string

@description('Name of the connected Container Registry')
param containerRegistryName string

@description('Name of the Container App Environment')
param containerAppEnvName string

@description('Name of the TodoApi Container App')
param todoApiContainerName string

param location string = resourceGroup().location

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2021-12-01-preview' = {
  name: logAnalyticsName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-12-01-preview' = {
  name: containerRegistryName
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
}

resource containerAppEnvironment 'Microsoft.Web/kubeEnvironments@2021-03-01' = {
  name: containerAppEnvName
  location: location 
  kind: 'containerenvironment'
  properties: {
    environmentType: 'managed'
    internalLoadBalancerEnabled: false
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalytics.properties.customerId
        sharedKey: logAnalytics.listKeys().primarySharedKey
      }
    }
  }
}

resource todoApiContainerApp 'Microsoft.Web/containerApps@2021-03-01' = {
  name: todoApiContainerName
  location: location
  properties: {
    kubeEnvironmentId: containerAppEnvironment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 80
        allowInsecure: false
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      }
      registries: [
        {
          server: containerRegistry.name
          username: containerRegistry.properties.loginServer
          passwordSecretRef: 'container-registry-password'
        }
      ]
      secrets: [
        {
          name: 'container-registry-password'
          value: containerRegistry.listCredentials().passwords[0].value
        }
      ]
    }
    template: {
      containers: [
        {
          name: todoApiContainerName
          image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
          resources: {
            cpu: '0.5'
            memory: '1Gi'
          }         
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
} We will also need to provide a parameter file to accompany our Bicep template. Like ARM, this is just a JSON file. We could provide parameters via the AZ CLI, but in future posts, I want to deploy my Bicep template via GitHub Actions, so we'll start with a parameter file. Our parameter file will look like this (You'll need to provide your own values): {
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "logAnalyticsName": {
        "value": "<log-analytics-workspace-name>"
      },
      "containerAppEnvName": {
          "value": "<container-environment-name>"
      },
      "todoApiContainerName": {
          "value": "<container-app-name>"
      },
      "containerRegistryName": {
          "value": "<container-registry-name>"
      }
    }
  } We can now deploy our Bicep template. As you can see within the Bicep template, I've set the parameter to be the location of the resource group that we will deploy our Container App resources to. location At the time of writing, Container Apps can only be provisioned in the following environments: East US North Europe Canada Central East US 2 West Europe With that in mind, we'll create a resource group that we'll deploy our resources to by running the following AZ CLI command. az group create --name <name-of-your-resource-group> --location <one-of-the-above-locations> We now have a resource group to deploy our Container App resources to. Let's do that by running the following command: az deployment group create --resource-group <name-of-your-resource-group> --template-file <your-bicep-file>.bicep --parameters --<your-parameter-file>.json Give that a couple of minutes to run and we should see the following output: Click on and we should see that all the resources we defined in our Bicep template have been deployed to Azure! Go to the resource group Let's see how our Container App is doing! Click on your Container App resource and you should see an Application Url (since we enabled external ingress in our Container App). Navigate to it and you should see the following web page: Awesome! We've just deployed an Azure Container App in a Container App environment that sends logs to our Log Analytics workspace and can pull images from our Azure Container Registry in just one Bicep file! Good job! 👏👏 Wrapping Up As you can see, we can manage and deploy our Container Apps using Bicep! As this awesome product grows, more features will be released meaning that we can extend our Bicep template further ( ) vNet integration comes to mind If you want a reference to the code that we've written in this post, you can do so in this . GitHub repository In a future post, we'll deploy our Bicep template via GitHub actions rather than running AZ CLI commands on our local machine each time we want to deploy our Container Apps. If you have any questions, feel free to reach out to me on Twitter @willvelida Until next time, Happy coding! 🤓🖥️

Creating and Provisioning Azure Container Apps with Bicep

AWS EKS provides managed Kubernetes clusters as a service. You’re on AWS and want to avoid getting into the details of setting up a Kubernetes cluster from scratch? EKS is the way to go! In this guide, you will learn how to provision an AWS EKS Kubernetes cluster with Terraform. Let’s start with the basics. Step 1 - Install Terraform Locally First, locally install Terraform: brew install terraform as well as the AWS CLI: brew install awscli and kubectl: brew install kubernetes-cli If you’re on a different operating system, please find the respective installation instructions here: Terraform: https://learn.hashicorp.com/tutorials/terraform/install-cli awscli: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html kubectl: https://kubernetes.io/docs/tasks/tools/ Step 2 - Configure the AWS CLI Now, you’ll need to configure your AWS CLI with access credentials to your AWS account. You can do this by running aws configure and providing your Access Key ID and Secret Access Key. You will also need to add the region. For the purposes of this guide, we will use us-east-2. Terraform will later use these credentials to provision your AWS resources. Step 3 - Get the Code You can now clone a repository which contains everything you need to set up EKS: git clone https://github.com/hashicorp/learn-terraform-provision-eks-cluster/ Inside you’ll see a few files, the main one being : eks-cluster.tf module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = local.cluster_name
  cluster_version = "1.20"
  subnets         = module.vpc.private_subnets

  tags = {
    Environment = "training"
    GithubRepo  = "terraform-aws-eks"
    GithubOrg   = "terraform-aws-modules"
  }

  vpc_id = module.vpc.vpc_id

  workers_group_defaults = {
    root_volume_type = "gp2"
  }

  worker_groups = [
    {
      name                          = "worker-group-1"
      instance_type                 = "t2.small"
      additional_userdata           = "echo foo bar"
      asg_desired_capacity          = 2
      additional_security_group_ids = [aws_security_group.worker_group_mgmt_one.id]
    },
    {
      name                          = "worker-group-2"
      instance_type                 = "t2.medium"
      additional_userdata           = "echo foo bar"
      additional_security_group_ids = [aws_security_group.worker_group_mgmt_two.id]
      asg_desired_capacity          = 1
    },
  ]
} It uses the EKS Terraform module to set up an EKS cluster with 2 worker groups (the actual nodes running your workloads): one with a single medium machine, and one with two small machines. Step 4 - Run Terraform You can now create all of those resources using Terraform. First, run terraform init -upgrade to initialize the Terraform workspace and download any modules and providers which are used. In order to do a dry run of the changes to be made, run terraform plan -out terraform.plan This will show you that 51 resources will be added, as well as their relevant details. You can then run terraform apply with the resulting plan, in order to actually provision the resources: terraform apply terraform.plan This may take a few minutes to finish. You might get a “timed out” error, in which case just repeat both the terraform plan and terraform apply steps. In the end you will get a list of outputs with their respective values printed out. Make note of your cluster_name. Step 5 - Connect with Kubectl In order to use kubectl, which is the main tool to interact with a Kubernetes cluster, you have to give it credentials to your EKS Kubernetes cluster. You can do this by running aws eks --region us-east-2 update-kubeconfig --name <output.cluster_name> Make sure to replace <output.cluster_name> with the relevant value from your Terraform apply outputs. Step 6 - Interact with Your Cluster You can now view the nodes of your cluster by running > kubectl get nodes -o custom-columns=Name:.metadata.name,nCPU:.status.capacity.cpu,Memory:.status.capacity.memory
Name                                       nCPU   Memory
ip-10-0-1-23.us-east-2.compute.internal    2      4026680Ki
ip-10-0-2-8.us-east-2.compute.internal     1      2031268Ki
ip-10-0-3-128.us-east-2.compute.internal   1      2031268Ki This command is so long because it displays custom columns, thanks to which we can indeed see that there are 2 smaller nodes, and 1 bigger node. Let’s deploy an Nginx instance to see if the cluster is working correctly. kubectl run --port 80 --image nginx nginx You can see the status of it by running: > kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m46s And finally set up a tunnel from your computer to this pod: kubectl port-forward nginx 3000:80 If you open in your browser, you should see the web server greet you: http://localhost:3000 Step 7 - Clean up In order to destroy the resources we’ve created in this session, run terraform destroy This may again take up to a few minutes. I hope this guide helped you on your Kubernetes journey on AWS! First Published here

Getting Started Provisioning an AWS EKS Kubernetes Cluster with Terraform

If you have ever developed an iOS app, or even started learning about it, then you must have been a bit (or a lot) confused about the process of app provisioning. I know for sure I was. So that’s why I decided to write this article explaining what in fact are these certificates and profiles, why we need them and a step by step tutorial of how to create and use them. And hopefully it will help some lost fellow out there who’s trying to find a point to this mystic process. So let’s dive into this! 👩‍💻 What are Apple certificates and provisioning profiles and why do we need them? The certificate is a digital identification you use to sign your iOS apps for development and distribution. The main part of the certificate is your public/private key pair, which is a guarantee that the apps are truly developed/distributed by you. You've probably realized by now that you can't install any app on an iOS device. It needs to be signed by Apple first and that's why we need the provisioning profiles. You can see them as a link between the device and the developer account. And if you’re wondering why is Apple requiring all of this? Well, because they are really focused towards providing secure devices. That's why their developers need to be registered, sign their apps and have them reviewed by Apple before any distribution. This is the process they came up with as a way to keep the security on a high level but still be accessible. Creating and using the certificates and provisioning profiles In order to create or use an existing certificate or provisioning profile login to your Apple developer account and you should see the homepage for your Apple developer program account. Navigate to Certificates, Identifiers & Profiles. Note: every certificate and provisioning profile have an expiration date, so it’s really important to check it before using any. Creating a certificate: In the certificates section you’ll see all of the current certificates that are made under that developer program. There are two types of certificates: and . Development Distribution The development one is used when you want to install the app using XCode (when developing an app), and the distribution one is used for distribution of the application (TestFlight/AppStore). If you want to use a current certificate then you can select it and download it, but you would also need to obtain the private key from the developer who created the certificate. 📎 Steps for creating a new certificate: select the plus icon and choose the type of certificate you need (distribution/development) and the type of service - if you have any click continue and you will be navigated to a page where you need to generate a Certificate Signing Request (CSR) file from your Mac. To create a CSR you need to follow these steps: Launch Keychain Access located in /Applications/Utilities. Choose Keychain Access > Certificate Assistant > Request a Certificate from a Certificate Authority. In the Certificate Assistant dialog, enter an email address in the User Email Address field. In the Common Name field, enter a name for the key (for example, Gita Kumar Dev Key). Leave the CA Email Address field empty. Choose “Saved to disk”, and click Continue. This example was taken from the official Apple guide You can now save the request and add it to the request field. After this the certificate is created and you can download it. . Find the downloaded certificate, double click on it and it should now appear in your Keychain The last step depends on whether the certificate is a distribution or development one. - you need to add it to your Keychain and in the Debug configuration of your project in the development environment that you use. Development certificate - you also need to add it in your project but under Release configuration (iOS bundle signing -> signing identity). Additionally, you will need to add the installation of the certificate as a task in your build pipeline (ex. Azure DevOps) before building the project. To do this, first you need to export the certificate from Keychain. Find the certificate in Keychain, right click on it and select export. It will require you to set a password for it, be sure to keep it somewhere because you’ll need it! Next, add the exported certificate with a .p12 format in the repo of the project and add it in the pipeline as well. Next, enter the password and the certificate signing identity (same as the name of the certificate in keychain). One last step is to go in the Build project task in the pipeline and add the same certificate signing identity in the Signing identity field Distribution certificate Creating a provisioning profile: The next thing we need to do if we want to develop or distribute our app is create a Provisioning profile (specific for the certificate that we just created). Each provisioning profile stores the following: certificate, an App ID (two-part string used to identify one or more apps from a single development team) and unique device identifiers (list of devices that the app can run on). Go back to Certificates, Identifiers & Profiles and under Provisioning profiles you will see all of the current profiles that are made under that Apple developer program. There are also two types of provisioning profiles: and . The development one is used for testing of the application, while the distribution one is used when we want to submit our app to AppStore/TestFlight. If you want to use a current profile then you can select it and download it. Distribution Development 📎 Steps for creating a new provisioning profile: select the plus icon and choose the type of profile that you want to create (development/distribution-app store or ad-hoc) next select an App ID - if you plan to use services such as Game Center, In-App Purchase, and Push Notifications, or want a Bundle ID unique to a single app, use an explicit App ID. If you want to create one provisioning profile for multiple apps or don't need a specific Bundle ID, select a Wildcard App ID. Wildcard App IDs use an asterisk (*) as the last digit in the Bundle ID field. in the next step choose what certificate and device/devices is this profile referred to name your profile, generate and download it after it is downloaded find it in your local storage and double click on it to install it in XCode - after successfully installing it you can add it in your project repo and in the project options under iOS Bundle Signing - Provisioning profile in your developing environment The last step here also depends on whether the certificate is a distribution or development one: - you need to select it in your project options under Debug configuration, but be careful, the profile will only appear in the selection list if you have previously selected the certificate that this profile is created for Development profile besides adding it to the project options under Release configuration, you will also need to add the installation of the profile in your build pipeline (ex. Azure DevOps) before or after installing the certificate. To do this, you just need to select the profile from the project repo in the Provisioning profile field. Additionally, under the Build project task in the pipeline you will need to enter the Provisioning profile UUID which can be found in XCode or by right click on the profile and . Distribution profile Get info As mentioned before the certificates and provisioning profiles have their expiration dates. After the expiration date has passed, you will need to create new ones in order to keep working on your app. With all of this set you're ready to go and develop or distribute your iOS app! 📲 Previously published at https://blog.codechem.com/apple-certificates-and-provisioning-profiles-a-mystery-resolved

Developing & Distributing iOS apps: Apple Certificates and Provisioning Profiles

Poe knows a fair bit about automating There is a plethora of products who want to help us with running our application in the cloud. Unfortunately, none of them covers the entirety of what we need. Sometimes we need to bring our own server. Or they take care of hosting but we can’t access the underlying infrastructure. So not only we pay for them, bet on closed-source software and there are handling only a fraction of what we need. . We’ll be doing this using Infrastructure-as-code and Configuration-as-code, for the process to be repeatable, shareable and documented. I’m sharing a full Terraform and Docker configuration that lets you provision AWS and deploy Laravel / Nginx / MySQL / Redis / ElasticSearch from scratch, in a few commands A word about automating: The deeper we automate, the more standard our processes become. We will replace your stray scripts by universally understood technologies like Docker, , Kubernetes, Consul etc and their design patterns. We can build and handover them to a new developer quickly. We can forget about them and get back to it months later with no brain freeze. automating is the only way we can grow your technical teams efficiently. Terraform The full source code we need to deploy Laravel on is publicly available on GitHub here: AWS _laravel-terraform - 1-click deployment of Laravel - without paying for an extra Saas_github.com li0nel/laravel-terraform Ready? Let’s start! This is a procedure I use to deploy my clients’ Laravel applications on AWS. I hope this can be helpful to deploy yours. If your use case is more complex, I provide on-going support packages ranging from mentoring your developers up to hands-on building your application on AWS. Ping me at hi@getlionel.com 1. Clone the deployment scripts We start by downloading the Terraform and Docker scripts we need to deploy Laravel. From our Laravel root directory: git clone git@github.com:li0nel/laravel-terraform deploy This will create a deploy directory at the root of our Laravel installation. For now, we’re going to use the Terraform scripts from that directory to create our infrastructure. ├── deploy└── terraform ├── master.tf               # ├── terraform.tfvars        # └── modules└── vpc                   # ├── vpc.tf└── outputs.tf└── ec2 ├── ec2.tf└── outputs.tf└── aurora      _          # Aurora configuration_├── aurora.tf└── outputs.tf└── s3 ├── s3.tf└── outputs.tf└── cron └── artisan-schedule-run└── nginx ├── default.conf├── nginx.conf└── ssl ├── ssl.cert└── ssl.key├── php-fpm ├── Dockerfile ├── Dockerfile-nginx └── docker-compose.yml # our Terraform scripts entrypoint for Terraform (TF) TF input variables VPC configuration # EC2 configuration # S3 configuration # cron configuration for Docker # Nginx configuration # Nginx SSL certificates # PHP-FPM config # Dockerfile for Laravel containers # Dockerfile for Nginx container # Docker Compose configuration 2. Configure our AWS command line We start with authenticating our command line by downloading the API key and secret for a new user in the IAM section of our AWS console. This user will need to have to have permissions to create resources for all the services we will use below. Follow the prompts from: aws configure 3. Update Terraform input variables Terraform automatically loads input variables from any or present in the current directory. terraform.tfvars *.auto.tfvars 4. Build our infrastructure with Terraform Let’s check what Terraform is about to build for us in our AWS account with : terraform plan These are the 33 infrastructure parts needed to deploy Laravel on AWS. It would easily be ~60 of them once we include monitoring alerts, database replicas and an auto-scaling group. Can you see how risky and painful it would be to set that up manually in the AWS console for every new project? The command to execute the setup is terraform apply plan.tf Terraform created our infrastructure in less than 8 minutes Terraform can not only make us extremely efficient, but is also a real pleasure to write infrastructure with. Look at an example of its syntax: 2 things to remember when using Terraform: — We tag every resource we can with our project name, to identify them in the AWS console — We will setup Terraform to store our state file on S3 (more info in step 7 below) ! If we don’t, and accidentally overwrite our state file, Terraform would have stopped tracking our stack and we need to go and manually delete everything in the console. and make sure is enabled bucket versioning 4. (Optional) Cloning our stack A great feature of Terraform is that it can not only keep track of our infrastructure, but also different versions of it (i.e. test, staging, production). Think of it like Git Branches. Terraform calls its versions . Here’s how it works: Workspaces Creating the exact same stack, in production Switching back to our initial workspace 5. Install Docker on our EC2 instance using Docker Machine Docker Machine is the single easiest way to provision a new Docker host or . machine — it’s blazing fast — the command line is dead simple — it manages all of the SSH keys and TLS certificates even if we have dozens of servers — makes our servers immediately ready for Docker deployments Since we’ve already created an EC2 instance with Terraform, we then use the which creates using an existing VM/Host through SSH: Docker Machine Generic driver machines docker-machine create \  --driver generic \  --generic-ip-address=$(terraform output ec2_ip) \  --generic-ssh-key $(terraform output ssh_key_path) \ Docker Machine will connect to the remote server through SSH, install the Docker daemon and generate TLS certificates to secure the Docker daemon port.We can then connect at any point to our machine using , from which we can list running containers. eval "$(docker-machine env your_machine_name)" Provisioning our existing EC2 instance with the Docker daemon with Docker Machine 6. Build and deploy the Docker images with Docker Compose Great, we’re half-way through! We have a fully provisioned infrastructure we can now deploy our Laravel stack on. We’ll be deploying the following Docker containers: — our Laravel code in a PHP-FPM container — Nginx as a reverse proxy to PHP-FPM — (optional) Redis as a cache and queue engine to Laravel — (optional) ElasticSearch for our application search engine — our Laravel code in a container running , for artisan scheduled commands — our Laravel code in a worker container that will listen for Laravel Jobs from the Redis queue cron Just like we don’t want to manage all our infrastructure’s moving parts manually, there is NO WAY we will manage all of this configuration and orchestration manually. Docker Compose to the rescue! The configuration for all the above containers is committed into the Dockerfiles: └── deploy├── Dockerfile ├── Dockerfile-nginx └── docker-compose.yml # Dockerfile for Laravel containers # Dockerfile for Nginx container # Docker Compose configuration … and the script to orchestrate them all is the file: docker-compose.yml Copy these files at the root of your project: mv Dockerfile Dockerfile-nginx docker-compose.yml .dockerignore .. Then create a file for our remote environment variables: docker-compose.env cp .env docker-compose.env Update the file with appropriate env vars: — with the output of — with the output of — with the output of — with the output of — , , with docker-compose.env DB_HOST terraform output aurora_endpoint DB_DATABASE terraform output aurora_db_name DB_USERNAME terraform output aurora_master_username DB_PASSWORD terraform output aurora_master_password CACHE_DRIVER SESSION_DRIVER QUEUE_DRIVER redis We’re now ready to build our images and run our containers: docker-compose up --build -d Building and running all containers at once Let’s confirm that our Laravel code is correctly configured with the right database connection details, by running the default database migrations: Our Laravel project successfully connecting to Aurora …and that our web project is accessible on port 80: Laravel running in its Docker container on our Terraform-provisioned EC2 Each container’s log stream is centralised in our CloudWatch console 7. (Optional) Share access with teammates Amazing! We can now re-deploy your Laravel code at will, modify our infrastructure and configuration while keeping track of all changes in your code. Teammates can access all the Docker configuration and the Terraform files by pulling our code from our source code repository. However, at this stage, they can not: — modify the infrastructure or access Terraform outputs because they can’t access Terraform’s state file that is saved locally on our machine — connect their Docker client to our EC2 instance because they haven’t installed a Docker Machine pointing to that EC2 like we have The solution to the first point is to get Terraform to use the S3 remote , where the Terraform state is effectively saved remotely on an S3 bucket for sharing. This is done by un-commenting the following lines in and run to migrate the state to the new backend: backend master.tf terraform init It is strongly recommended to activate versioning on your S3 bucket to be able to retrieve your Terraform state should you overwrite it accidentally! Migrating Terraform’s state to S3 for security and collaboration Now, provided our colleagues use AWS credentials allowing access to our S3 bucket, they will connect to the same Terraform backend as we do, and we can work on the stack at the same time with no risk. 8. (Optional) Destroy and re-create your stack at will Congrats for making it that far in this guide! Once you’re done, clean up your infrastructure using so you don’t get a billing surprise at the end of the month. terraform destroy Lionel is Chief Technology Officer of London-based startup Wi5 and author of the Future-Proof Engineering Culture course . You can reach out to him on https://getlionel.com

Stop manually provisioning AWS for Laravel — use Terraform instead

Composing Contracts without Special Provisions — using Blockchain History

This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license.
Authors:
(1) Yejin Bang, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology;
(2) Nayeon Lee, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology;
(3) Pascale Fung, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology. Table of Links Abstract and Intro
Related Work
Approach
Experiments
Conclusion
Limitations, Ethics Statement and References
A. Experimental Details
B. Generation Results 6.1. Limitations The study is limited by its adherence to the benchmark’s English-based task setup. The analysis is constrained to political ideologies in the United States and the English language. Additionally, the BART model’s 1024 sub-token input limit restricts the number of biased source articles that can be included as an input. It is important to note that these limitations, while potentially impacting the scope of the study’s findings, are not uncommon in natural language processing research. Nonetheless, future research may benefit from addressing these limitations by exploring alternative methods for a broader range of political ideologies (NonU.S. political ideologies) and languages, as well as incorporating longer input texts to capture a more comprehensive range of source articles. 6.2. Ethics Statement The issue of biased articles with framing has been extensively studied, as it can lead to polarization by influencing readers’ opinions toward a certain person, group, or topic. To address this problem, our research focuses on introducing a loss function that can be incorporated to enable the model to reduce framing bias in the generated summary. However, it is important to recognize that automatic technologies can also have unintended negative consequences if not developed with careful consideration of their broader impacts. For example, machine learning models can introduce bias in their output, replacing known source bias with another form of bias (Lee et al., 2022). To mitigate this risk, Lee et al. (2022) have suggested including explicit mention of the source articles alongside automatically generated neutral summaries. Furthermore, while our work aims to remove framing bias in human-generated articles, there is the potential for hallucination in the generation, which is a well-known problem of generative models (Ji et al., 2023). Thus, it is important to equip a guardrail (e.g., a provision of source reference) if such automatic technology is implemented for actual use cases. Despite these challenges, our research can contribute to the effort of mitigating human-generated framing bias in order to reduce polarization in society. One of the use cases can be to aid human experts in the process of providing multi-view synthesized articles without framing bias. In terms of broader societal impact, we hope our work can help online users access more depolarized information online. 6.3. References 2021. Center – what does a "center" media bias rating mean? Ramy Baly, Giovanni Da San Martino, James Glass, and Preslav Nakov. 2020. We can detect your bias: Predicting the political ideology of news articles. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pages 4982–4991, Online. Association for Computational Linguistics. Adriana Beratšová, Kristína Krchová, Nikola Gažová, and Michal Jirásek. 2016. Framing and bias: a literature review of recent findings. Central European journal of management, 3(2). Dennis Chong and James N Druckman. 2007. Framing theory. Annu. Rev. Polit. Sci., 10:103–126. Robert M Entman. 2002. Framing: Towards clarification of a fractured paradigm. McQuail’s Reader in Mass Communication Theory. London, California and New Delhi: Sage. Robert M Entman. 2007. Framing bias: Media in the distribution of power. Journal of communication, 57(1):163–173. Robert M Entman. 2010. Media framing biases and political power: Explaining slant in news of campaign 2008. Journalism, 11(4):389–408. Alexander R Fabbri, Irene Li, Tianwei She, Suyi Li, and Dragomir R Radev. 2019. Multi-news: A large-scale multi-document summarization dataset and abstractive hierarchical model. arXiv preprint arXiv:1906.01749 Lisa Fan, Marshall White, Eva Sharma, Ruisi Su, Prafulla Kumar Choubey, Ruihong Huang, and Lu Wang. 2019. In plain sight: Media bias through the lens of factual reporting. arXiv preprint arXiv:1909.02670. Matthew Gentzkow and Jesse M Shapiro. 2006. Media bias and reputation. Journal of political Economy, 114(2):280–316. Matthew Gentzkow, Jesse M Shapiro, and Daniel F Stone. 2015. Media bias in the marketplace: Theory. In Handbook of media economics, volume 1, pages 623–645. Elsevier. Erving Goffman. 1974. Frame analysis: An essay on the organization of experience. Harvard University Press Felix Hamborg, Karsten Donnay, and Bela Gipp. 2019. Automated identification of media bias in news articles: an interdisciplinary literature review. International Journal on Digital Libraries, 20(4):391–415. Felix Hamborg, Norman Meuschke, and Bela Gipp. 2017. Matrix-based news aggregation: exploring different news perspectives. In 2017 ACM/IEEE Joint Conference on Digital Libraries (JCDL), pages 1–10. IEEE. Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. 2023. Survey of hallucination in natural language generation. ACM Comput. Surv., 55(12). Daniel Kahneman and Amos Tversky. 2013. Prospect theory: An analysis of decision under risk. In Handbook of the fundamentals of financial decision making: Part I, pages 99–127. World Scientific. Philippe Laban and Marti A Hearst. 2017. newslens: building and visualizing long-ranging news stories. In Proceedings of the Events and Stories in the News Workshop, pages 1–9. Nayeon Lee, Yejin Bang, Tiezheng Yu, Andrea Madotto, and Pascale Fung. 2022. NeuS: Neutral multi-news summarization for mitigating framing bias. In Proceedings of the 2022 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, pages 3131–3148, Seattle, United States. Association for Computational Linguistics. Mike Lewis, Yinhan Liu, Naman Goyal, Marjan Ghazvininejad, Abdelrahman Mohamed, Omer Levy, Ves Stoyanov, and Luke Zettlemoyer. 2019. Bart: Denoising sequence-to-sequence pre-training for natural language generation, translation, and comprehension. arXiv preprint arXiv:1910.13461. Yujian Liu, Xinliang Frederick Zhang, David Wegsman, Nicholas Beauchamp, and Lu Wang. 2022. POLITICS: Pretraining with same-story article comparison for ideology prediction and stance detection. In Findings of the Association for Computational Linguistics: NAACL 2022, pages 1354–1374, Seattle, United States. Association for Computational Linguistics. Saif Mohammad. 2018. Obtaining reliable human ratings of valence, arousal, and dominance for 20,000 english words. In Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 174–184. Fred Morstatter, Liang Wu, Uraz Yavanoglu, Stephen R Corman, and Huan Liu. 2018. Identifying framing bias in online news. ACM Transactions on Social Computing, 1(2):1–18. Kishore Papineni, Salim Roukos, Todd Ward, and WeiJing Zhu. 2002. Bleu: a method for automatic evaluation of machine translation. In Proceedings of the 40th annual meeting of the Association for Computational Linguistics, pages 311–318. Souneil Park, Seungwoo Kang, Sangyoung Chung, and Junehwa Song. 2009. Newscube: delivering multiple aspects of news to mitigate media bias. In Proceedings of the SIGCHI conference on human factors in computing systems, pages 443–452. Dietram A Scheufele. 2000. Agenda-setting, priming, and framing revisited: Another look at cognitive effects of political communication. Mass communication & society, 3(2-3):297–316. All Sides. 2018. Media bias ratings. Allsides.com. Timo Spinde, Christina Kreuter, Wolfgang Gaissmaier, Felix Hamborg, Bela Gipp, and Helge Giese. 2021. Do you think it’s biased? how to ask for the perception of media bias. In 2021 ACM/IEEE Joint Conference on Digital Libraries (JCDL), pages 61–69. IEEE. Esther van den Berg and Katja Markert. 2020. Context in informational bias detection. In Proceedings of the 28th International Conference on Computational Linguistics, pages 6315–6326, Barcelona, Spain (Online). International Committee on Computational Linguistics. George Wright and Paul Goodwin. 2002. Eliminating a framing bias by using simple instructions to ‘think harder’and respondents with managerial experience: Comment on ‘breaking the frame’. Strategic management journal, 23(11):1059–1067. Jingqing Zhang, Yao Zhao, Mohammad Saleh, and Peter J. Liu. 2019a. Pegasus: Pre-training with extracted gap-sentences for abstractive summarization. Tianyi Zhang*, Varsha Kishore*, Felix Wu*, Kilian Q. Weinberger, and Yoav Artzi. 2020. Bertscore: Evaluating text generation with bert. In International Conference on Learning Representations. Yifan Zhang, Giovanni Da San Martino, Alberto BarrónCedeno, Salvatore Romeo, Jisun An, Haewoon Kwak, Todor Staykovski, Israa Jaradat, Georgi Karadzhov, Ramy Baly, et al. 2019b. Tanbih: Get to know what you are reading. EMNLP-IJCNLP 2019, page 223. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. Authors: (1) Yejin Bang, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology; (2) Nayeon Lee, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology; (3) Pascale Fung, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. Authors: Authors: (1) Yejin Bang, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology; (2) Nayeon Lee, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology; (3) Pascale Fung, Centre for Artificial Intelligence Research (CAiRE), The Hong Kong University of Science and Technology. Table of Links Abstract and Intro Related Work Approach Experiments Conclusion Limitations, Ethics Statement and References A. Experimental Details B. Generation Results Abstract and Intro Abstract and Intro Related Work Related Work Approach Approach Experiments Experiments Conclusion Conclusion Limitations, Ethics Statement and References Limitations, Ethics Statement and References A. Experimental Details A. Experimental Details B. Generation Results B. Generation Results 6.1. Limitations The study is limited by its adherence to the benchmark’s English-based task setup. The analysis is constrained to political ideologies in the United States and the English language. Additionally, the BART model’s 1024 sub-token input limit restricts the number of biased source articles that can be included as an input. It is important to note that these limitations, while potentially impacting the scope of the study’s findings, are not uncommon in natural language processing research. Nonetheless, future research may benefit from addressing these limitations by exploring alternative methods for a broader range of political ideologies (NonU.S. political ideologies) and languages, as well as incorporating longer input texts to capture a more comprehensive range of source articles. 6.2. Ethics Statement The issue of biased articles with framing has been extensively studied, as it can lead to polarization by influencing readers’ opinions toward a certain person, group, or topic. To address this problem, our research focuses on introducing a loss function that can be incorporated to enable the model to reduce framing bias in the generated summary. However, it is important to recognize that automatic technologies can also have unintended negative consequences if not developed with careful consideration of their broader impacts. For example, machine learning models can introduce bias in their output, replacing known source bias with another form of bias (Lee et al., 2022). To mitigate this risk, Lee et al. (2022) have suggested including explicit mention of the source articles alongside automatically generated neutral summaries. Furthermore, while our work aims to remove framing bias in human-generated articles, there is the potential for hallucination in the generation, which is a well-known problem of generative models (Ji et al., 2023). Thus, it is important to equip a guardrail (e.g., a provision of source reference) if such automatic technology is implemented for actual use cases. Despite these challenges, our research can contribute to the effort of mitigating human-generated framing bias in order to reduce polarization in society. One of the use cases can be to aid human experts in the process of providing multi-view synthesized articles without framing bias. In terms of broader societal impact, we hope our work can help online users access more depolarized information online. 6.3. References 2021. Center – what does a "center" media bias rating mean? Ramy Baly, Giovanni Da San Martino, James Glass, and Preslav Nakov. 2020. We can detect your bias: Predicting the political ideology of news articles. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pages 4982–4991, Online. Association for Computational Linguistics. Adriana Beratšová, Kristína Krchová, Nikola Gažová, and Michal Jirásek. 2016. Framing and bias: a literature review of recent findings. Central European journal of management, 3(2). Dennis Chong and James N Druckman. 2007. Framing theory. Annu. Rev. Polit. Sci., 10:103–126. Robert M Entman. 2002. Framing: Towards clarification of a fractured paradigm. McQuail’s Reader in Mass Communication Theory. London, California and New Delhi: Sage. Robert M Entman. 2007. Framing bias: Media in the distribution of power. Journal of communication, 57(1):163–173. Robert M Entman. 2010. Media framing biases and political power: Explaining slant in news of campaign 2008. Journalism, 11(4):389–408. Alexander R Fabbri, Irene Li, Tianwei She, Suyi Li, and Dragomir R Radev. 2019. Multi-news: A large-scale multi-document summarization dataset and abstractive hierarchical model. arXiv preprint arXiv:1906.01749 Lisa Fan, Marshall White, Eva Sharma, Ruisi Su, Prafulla Kumar Choubey, Ruihong Huang, and Lu Wang. 2019. In plain sight: Media bias through the lens of factual reporting. arXiv preprint arXiv:1909.02670. Matthew Gentzkow and Jesse M Shapiro. 2006. Media bias and reputation. Journal of political Economy, 114(2):280–316. Matthew Gentzkow, Jesse M Shapiro, and Daniel F Stone. 2015. Media bias in the marketplace: Theory. In Handbook of media economics, volume 1, pages 623–645. Elsevier. Erving Goffman. 1974. Frame analysis: An essay on the organization of experience. Harvard University Press Felix Hamborg, Karsten Donnay, and Bela Gipp. 2019. Automated identification of media bias in news articles: an interdisciplinary literature review. International Journal on Digital Libraries, 20(4):391–415. Felix Hamborg, Norman Meuschke, and Bela Gipp. 2017. Matrix-based news aggregation: exploring different news perspectives. In 2017 ACM/IEEE Joint Conference on Digital Libraries (JCDL), pages 1–10. IEEE. Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. 2023. Survey of hallucination in natural language generation. ACM Comput. Surv., 55(12). Daniel Kahneman and Amos Tversky. 2013. Prospect theory: An analysis of decision under risk. In Handbook of the fundamentals of financial decision making: Part I, pages 99–127. World Scientific. Philippe Laban and Marti A Hearst. 2017. newslens: building and visualizing long-ranging news stories. In Proceedings of the Events and Stories in the News Workshop, pages 1–9. Nayeon Lee, Yejin Bang, Tiezheng Yu, Andrea Madotto, and Pascale Fung. 2022. NeuS: Neutral multi-news summarization for mitigating framing bias. In Proceedings of the 2022 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, pages 3131–3148, Seattle, United States. Association for Computational Linguistics. Mike Lewis, Yinhan Liu, Naman Goyal, Marjan Ghazvininejad, Abdelrahman Mohamed, Omer Levy, Ves Stoyanov, and Luke Zettlemoyer. 2019. Bart: Denoising sequence-to-sequence pre-training for natural language generation, translation, and comprehension. arXiv preprint arXiv:1910.13461. Yujian Liu, Xinliang Frederick Zhang, David Wegsman, Nicholas Beauchamp, and Lu Wang. 2022. POLITICS: Pretraining with same-story article comparison for ideology prediction and stance detection. In Findings of the Association for Computational Linguistics: NAACL 2022, pages 1354–1374, Seattle, United States. Association for Computational Linguistics. Saif Mohammad. 2018. Obtaining reliable human ratings of valence, arousal, and dominance for 20,000 english words. In Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 174–184. Fred Morstatter, Liang Wu, Uraz Yavanoglu, Stephen R Corman, and Huan Liu. 2018. Identifying framing bias in online news. ACM Transactions on Social Computing, 1(2):1–18. Kishore Papineni, Salim Roukos, Todd Ward, and WeiJing Zhu. 2002. Bleu: a method for automatic evaluation of machine translation. In Proceedings of the 40th annual meeting of the Association for Computational Linguistics, pages 311–318. Souneil Park, Seungwoo Kang, Sangyoung Chung, and Junehwa Song. 2009. Newscube: delivering multiple aspects of news to mitigate media bias. In Proceedings of the SIGCHI conference on human factors in computing systems, pages 443–452. Dietram A Scheufele. 2000. Agenda-setting, priming, and framing revisited: Another look at cognitive effects of political communication. Mass communication & society, 3(2-3):297–316. All Sides. 2018. Media bias ratings. Allsides.com. Timo Spinde, Christina Kreuter, Wolfgang Gaissmaier, Felix Hamborg, Bela Gipp, and Helge Giese. 2021. Do you think it’s biased? how to ask for the perception of media bias. In 2021 ACM/IEEE Joint Conference on Digital Libraries (JCDL), pages 61–69. IEEE. Esther van den Berg and Katja Markert. 2020. Context in informational bias detection. In Proceedings of the 28th International Conference on Computational Linguistics, pages 6315–6326, Barcelona, Spain (Online). International Committee on Computational Linguistics. George Wright and Paul Goodwin. 2002. Eliminating a framing bias by using simple instructions to ‘think harder’and respondents with managerial experience: Comment on ‘breaking the frame’. Strategic management journal, 23(11):1059–1067. Jingqing Zhang, Yao Zhao, Mohammad Saleh, and Peter J. Liu. 2019a. Pegasus: Pre-training with extracted gap-sentences for abstractive summarization. Tianyi Zhang*, Varsha Kishore*, Felix Wu*, Kilian Q. Weinberger, and Yoav Artzi. 2020. Bertscore: Evaluating text generation with bert. In International Conference on Learning Representations. Yifan Zhang, Giovanni Da San Martino, Alberto BarrónCedeno, Salvatore Romeo, Jisun An, Haewoon Kwak, Todor Staykovski, Israa Jaradat, Georgi Karadzhov, Ramy Baly, et al. 2019b. Tanbih: Get to know what you are reading. EMNLP-IJCNLP 2019, page 223.

Stories, News & Mentions about PROVISION

Provision’s Stories on HackerNoon