Beginis in the AI Infrastructure Industry

Begin

Photo by on Jp Valery Unsplash Architect users often ask for some way to avoid large surprise bills from AWS. The budget-watch plugin sets a cost limit for your app and temporarily shuts it down when the limit is reached. It is the first step to solving this problem for our community. Scaling is a built-in feature of dynamic apps using cloud functions. But if your app can scale to infinity, so can your bill. Many users have this concern, even though it rarely happens. Amazon has many services to help monitor billing. Setting an account-wide budget alert is a relatively easy first line of defense. But configuring more fine-grained monitoring for a single app is not so easy. It’s a little like trying to fix your car by breaking into your mechanic’s garage. The billing services are too complicated for a small team to devote their limited resources to. The unit of deployment in Architect is an individual app. None of the AWS budget solutions easily scope to a single app. You might have one app you expect to cost $100 per month and a dozen other experimental apps that you expect to be free. You should be able to easily set these limits and have some assurance there will be no surprises. What Budget-Watch Does There are many ways an app could run up your bill. Maybe you hit the top of hacker news, or you might have an infinite loop. The simplest way to stop a runaway app is to shut down the compute resources. By setting reserved concurrency (how many simultaneous executions can run) on all lambdas to zero, you can effectively stop most things that cost money in your app. You install the plugin with , and then add the four lines shown below to your app manifest. npm install @architect/plugin-budget-watch @plugins
budget-watch

@budget
limit $40 If the app uses multiple plugins, budget-watch should be listed last so that it is the last one applied. When deployed, it attaches a budget alert scoped to just the resources of the app. If the cost of those resources exceeds the limit set, a shutdown is triggered. To restart the app, the limit can be increased or removed and the app redeployed. This resets the lambda concurrency, and the app will resume operation. You can see the code on for more details. github.com/architect/plugin-budget-watch Implementation details (the messy parts) We would love to see Amazon build this feature into the platform. Solving this problem from the outside exposes many rough edges in the billing and CloudFormation APIs. The three biggest challenges are: Enabling tags Slow billing updates Managing configuration drift Enabling Tags An ideal solution would be deployed entirely through the app manifest using CloudFormation (AWS’s infrastructure as code that Architect uses underneath). All that is needed to scope to an app is a single auto-generated tag ( ). But before this tag can be used, someone needs to navigate deep into the AWS console to activate it. This only needs to be done once, but it breaks the ideal user experience of avoiding the console altogether. Some users may not be allowed to activate tags because of account limits set by their organization. aws:cloudformation:stack-name Billing Updates Amazon bills you by the millisecond but only lets you check three times a day. It’s like touching a stove and finding out eight hours later that you got burned. You can set all kinds of alerts on all sorts of dimensions, but you can’t do any better than 8-12 hours of granularity. Even if you set an alert for a limit you have already passed, the notification may still be delayed for half a day until the next billing update. Drift detection Deterministic deploys are a core feature of Architect. You get the same infrastructure every time you deploy the same app manifest. This plugin should not break that contract. Setting a budget limit and resetting it after it has triggered are all done from the app manifest. To shut down the app, the plugin changes all concurrency by directly calling the lambda API. This causes a drift (out of band configuration changes to infrastructure) between your app and manifest. This drift needs to be reversed if the app is restarted. If you deploy the same CloudFormation template, it will not make any update because the template has not changed. AWS has “Drift Detection” that you can enable to monitor the out-of-band changes, but it requires clicking around the console to enable it. There is no way to turn drift detection on with CloudFormation, and there is no way to automatically reconcile that drift by having your template overwrite those configuration changes. Not only that, drift detection does not even monitor the relevant lambda configurations. The workaround for this drift reset is to use a CloudFormation Custom Resource as a reset mechanism. Custom resources are intended for provisioning infrastructure outside of AWS and connecting them to your stack through CloudFormation. They have lifecycle hooks for creating, updating, and deleting that run custom logic. After the budget-watch limit is triggered, it can be reset by increasing the limit in the manifest or by removing the limit. This triggers an update in the custom resource that resets the concurrency back to its original settings. Other approaches considered There are many ways to build a feature like this with AWS building blocks, but most suffer from the same limitations (i.e., 3x/day updates). Two promising approaches considered were cost anomaly detection w/SNS alerts and budget-triggered actions. Cost anomaly detection was not used primarily because the alerts look for deviations in billing rather than absolute limits. What is the “expected” budget for the app I just deployed for the first time? Budget-triggered actions seemed like the most promising solution provided by AWS. You set a budget with an alert that has automated actions attached. The challenge is that the actions you can specify are permissions, policy, and instance-based. These actions end up tightly coupled to implementation details of the app and must be updated as the app changes. Limitations The actual causes of large surprise bills are as varied as the many services that AWS offers. This solution cannot possibly catch every single one. It focuses on the biggest source and applies the broadest intervention. Architect is a very flexible framework. It is possible (especially with custom plugins) to include infrastructure that will not be shut down by budget-watch. This plugin is still in Beta. We encourage people to try it out and give feedback. If you want to add the plugin to your Architect project you can follow the instruction in the GitHub repository ( ). architect/plugin-budget-watch What about Begin users? has a generous free tier, so users do not have to worry about costs. But for those on the paid tier, we will soon make this feature available to all users of Begin. We hope that AWS will build this into the platform in a more usable way. Until then, we hope to relieve some of the fear of unexpected bills. If you want to build scalable web apps with Begin for a free account today. Begin.com sign up

Avoid Surprise Bills from AWS: 'Begin' Saving Today

The debate over whether to use a single-purpose function vs. a fat lambda continues to this day, and in this post, we hope to convince you that Fat Lambda is truly an anti-pattern. What is a Fat Lambda? A fat lambda is a pattern in which you group related code together in one or more files. This lambda uses internal routing to decide what code to execute based on the invocation event. The internal routing may be hardcoded: exports.handler =  async function (event, context) {
    const { path, httpMethod: method  } = event
    if (path === '/apps' && method === 'GET') {
        // get apps
    }
    else if (path === '/apps' && method === 'POST') {
        // create app
    }
    else if (path.startsWith('/apps') && method === 'PUT') {
        // update app
    }
    else if (path.startsWith('/apps') === '/user'
             && method === 'DELETE') {
        // delete app
    }
} or it could be using some middleware like Express: let arc = require('@architect/functions')
let express = require('express')

let app = express()
app.post('/apps', (req, res) => // Add App)
app.get('/apps', (req, res)=> // List Apps)
app.put('/apps/:id', (req, res)=> // Update App)
app.delete('/apps/:id', (req, res)=> // Delete App)

exports.handler = arc.http.express(app) Pros Related code is grouped together. Code is shared between event handlers. Cons Cold start time increases for every extra byte of code you add to your lambda. Changes to the way you handle one event necessitate updating the handlers for all the events. Fat functions do not follow the . single responsibility principle Higher cognitive burden when you need to modify the function. Routing logic needs to be hardcoded or delegated to another package like express. So What's the Alternative? Instead of creating a single function that handles multiple responsibilities, we have the single-purpose function pattern where many functions do only one thing. // add-app.js
exports.handler =  async function (event, context) {
    // add app
}
// get-app.js
exports.handler =  async function (event, context) {
    // get apps
}
// update-app.js
exports.handler =  async function (event, context) {
    // update app
}
// delete-app.js
exports.handler =  async function (event, context) {
    // delete app
} Pros Easier to optimize the function to reduce cold start times. Smaller lambdas make it easier to write testable code. It follows the single responsibility principle. Lower cognitive load when making changes to individual lambda. Routing logic is offloaded to CloudFormation/API Gateway. Cons Harder to share code between lambda. Maintaining multiple lambdas can be tiresome. Evaluating Fat Functions vs. Single Purpose Functions Fat Functions have a few pros over single-purpose functions, but I would argue that they do not override their negatives. Proponents of Fat Functions say that grouping related code and sharing code between event handlers is a significant advantage. However, using tools like or makes managing many functions and sharing code much more straightforward. Architect Serverless Now on to the cons. Cold starts Lambda functions are dynamically provisioned. When you request a lambda, it runs through the following steps: Downloads your code Start new execution environment Execute initialization code Execute the handler code The time in which it takes to complete the first three steps is what we consider the cold start penalty. This gives us a couple of levers we can pull to reduce cold start times. The first is memory allocated to the lambda. What is somewhat surprising about our findings is that the amount of memory allocated to your lambda has a negligible impact on cold start times. The other lever we can pull is code size. We were looking at cold start times using a package with a JavaScript function and several large binary files to increase the package size. None of these binary files are referenced from the JavaScript function, so they are never parsed/interpreted. They are merely included to increase the package size. We can see that downloading and unzipping the package does not affect the cold start time. However, when we increase the code complexity so that the runtime environment loads and parses more JavaScript, we immediately impact cold start times. We start with a base JavaScript function that includes no external dependencies and then increase the amount of code parsed during the code initialization phase. Avoiding fat functions and sticking with single-purpose functions limit the cold start penalty when running your lambdas. Reduce Update Thrashing When you deploy a change to a single-purpose function, you only update the code for handling a single event type. However, with fat functions, you update the code that handles multiple event types, which increases the likelihood of introducing bugs in unrelated code paths. Therefore you have to do more testing to ensure you are not affecting your production environment. Single Responsibility Principle The single-responsibility principle (SRP) states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part. All of that module, class or function's services should be narrowly aligned with that responsibility. Fat functions don't adhere to the SRP. In the above example, our fat function is responsible for creating, updating, reading, and deleting our apps. It also means our fat function does not follow the as it requires the ability to read, write and delete apps from our database. principle of least privilege Decomposing the fat function into single-purpose functions follows SRP and allows us to assign the lowest level of permissions to each function. Cognitive Burden Proponents of fat functions state that grouping related code together reduces the cognitive burden of maintaining the code, whereas we would argue that it is precisely the opposite: It is harder to tell from the outside exactly what responsibilities a fat function has as they are a multitude. In contrast, suitably named single-purpose functions like or are pretty self-explanatory. get-apps delete-apps-appID Debugging fat functions because of their branching structure could take more effort to understand, while a single purpose function is relatively straightforward. Fat functions often make debugging more difficult by bundling back-end code, another anti-pattern we will address in a future post. Whereas single-purpose functions generally product stack traces that point exactly to the line of code where the error occurred. In Conclusion The allure of fat functions to quickly convert a node application into “serverless” application is appealing, but the work doesn’t stop there. If you are currently running a monolithic node application, you can wrap your app in the and then decompose it into single-purpose functions. By breaking the app down into single-purpose functions over time, you will reap the most benefits. Architect Express Migration Helper First Published here

Why you Should Stop Using Fat Functions in Your Lambda Code

One of the books that caught my eye for technical development recently was the popular . Staff Engineer by Will Larson What really drew me to the book was the in-depth interviews with 14 people that were Staff Engineers who spanned the archetypes that he discusses in the book. For those of you that haven’t read the book, the archetypes are: typically scopes complex tasks, coordinates their team towards solving a problem, and unblocking them as necessary. They also closely partner with the team’s product manager. Tech Lead - responsible for the success of a specific technical domain within their company where the domain is complex and central to the company’s success. Architect - solves complex problems that are typically high-risk and need a clear approach. Solver - operates as a senior leader without direct managerial responsibilities. Right Hand - 9 Lessons I Learned from The Book Find work that energizes you Staff engineer at Stripe, Michelle Bu, talks about the importance of finding work that keeps her energized over work that is impactful. Her distinction between energized and impactful is the former is more inward-looking while the latter is more company-centric. I think at times, we feel pressure to take on the work that has the highest visibility because it will be what is easiest to call out in a promotion packet or what will stand out to senior organization members. However, work that excites you is essential to keep you motivated and enthusiastic. Teams or team leaders should make an effort to increase visibility for work that is not flashy but just as important such as work to reduce on-call noise, etc. I think it pays to take a look at the things you’re doing day-to-day and figure out what actually gets you enthusiastic and seeking out similar work. Be deliberate about learning Michelle Bu, also talks about being thoughtful about her technical gaps and being intentional about filling in those gaps by carefully choosing projects to work on. As a software engineer, it is very easy to repeat the same year, every year. By that, I mean you can have made little to no progress on your technical skills year after year if you’re not intentional about what you want to learn. In larger organizations, it’s easy to keep signing up to take on the type of work you already know how to do instead of challenging yourself and taking on work you think you might fail at. Whether it's learning through external courses, expanding the type of material you’re reading, or actively pursuing projects that use technologies you’re unfamiliar with, you have to intentionally get uncomfortable to grow. Be picky (if you can) about where you work I understand that not all of us have this luxury, but the general idea is to focus on working somewhere that will help you grow in ways that you want to and being intentional about where you’re going to get that growth. I’ve personally found that having a quarterly check in with myself and re-evaluating my current skills, what I want to gain, how I think I should grow has helped me be honest and objective with myself about my growth, and my growth at my company. Make an effort to make connections Make an effort to establish good relationships with peers, senior leaders with your company and people in the industry in general. This will help you in the long run when you may need to convince decision-makers to see your point of view or get buy-in for technical decisions. Senior Staff Engineer at Split, Joy Ebertz, says in his interview “The more senior you get, the less your job is about code.” Nelson Elhage, former Staff Engineer at Stripe, highlights that it's important to have good relationships with engineering leadership so you know what problems they perceive that you don’t perceive and you can understand what their incentives are. Cultivate a good relationship with your manager Bert Fan, Senior Staff Engineer at Slack, calls this out in his interview. He explains that developing a relationship with your manager where you trust one another will result in your manager handing you important projects. If you successfully execute on the project, it will be easier for your manager and yourself, to advocate for your promotion. In cultivating a good relationship with your manager, it is also important to be honest and open with them about what you want to do instead of just telling them what they want to hear. Remember that your manager's success depends on your success and you should be honest with them about what you like/dislike. When you notice problems, act on them instead of letting them go This theme was common in many of the interviews. One staff engineer said the higher up you go, the more you have to care about. The more junior you are, the more you can get away with not caring about things and assuming that it's someone else’s problem. The attitude of caring and taking responsibility, will show itself to the people around you. If you care about your impact and take responsibility for the effect that your code/what you do has on your product/codebase, it will show itself in your PR’s, in how you respond to Slack messages, and your in your depth of knowledge. If you don't care, then it might be a good time to dig deeper and figure out why. Follow your passions Acknowledge what you’re good at, what you care about and try to do more of that. We weren’t all made to churn out thousands of lines of code, or build complex architecture. However, we do each have different skills and strengths that we bring to the table which if cultivated, can do some real damage. Figure out what your strengths are and how you can apply them in the context of your role. Rick Boone talked about how he had always been fascinated by human psychology and behavior and his natural interest helped him excel at his role as Strategic Advisor to the VP of Infrastructure at Uber. So, figure out what you like, and how you can apply it to your role. Stay up to date A lot of the Staff Engineers interviewed seem to all have different resources that they learned from but some popular methods are following leaders in tech on Twitter and reading books. Some names mentioned for Twitter and personal blogs were Camille Fournier, Lara Hogan, David Fowler, Tanya Reilly. Some books mentioned include Radical Candor, , 7 Habits of Highly Effective People. Depending on the type of material you like to consume; social media, books, podcasts, Youtube videos….there’s ways to stay up-to-date in the medium that you want. Spend a little time figuring out what works for you! Fundamentals of Software Architecture Develop more context A theme that constantly came up was about how the higher up the ladder you go, the more distanced you become from the problems on the ground. Some of the ways that the leaders in the book described developing context to make decisions was paying attention to slack channels where bugs were posted, continuing to attend team standups, being assigned low priority tickets so they could still code, and finally having chats with engineers talking about what they’re working on, what problems they’re facing and what their ideal solutions would be. For engineers who aren’t managing people, its never too early to cultivate the habit of putting feelers out to know what’s going on around you. It's easy to get caught up in your day-to-day work bubble and the immediate concerns of your own projects. If you have the bandwidth, I’d say its never too early to start practicing the skills you need, like developing context, as you transition to more senior software engineering roles. “We are what we repeatedly do. Excellence, then, is not an act, but a habit.” — Will Durant

9 Lessons for Engineers of All Levels from 'Staff Engineer' by Will Larson 

Set Up Your First Machine Learning Pipeline With This Beginner’s Guide 

Author:
(1) David Staines. Table of Links Abstract 1 Introduction 2 Mathematical Arguments 3 Outline and Preview 4 Calvo Framework and 4.1 Household’s Problem 4.2 Preferences 4.3 Household Equilibrium Conditions 4.4 Price-Setting Problem 4.5 Nominal Equilibrium Conditions 4.6 Real Equilibrium Conditions and 4.7 Shocks 4.8 Recursive Equilibrium 5 Existing Solutions 5.1 Singular Phillips Curve 5.2 Persistence and Policy Puzzles 5.3 Two Comparison Models 5.4 Lucas Critique 6 Stochastic Equilibrium and 6.1 Ergodic Theory and Random Dynamical Systems 6.2 Equilibrium Construction 6.3 Literature Comparison 6.4 Equilibrium Analysis 7 General Linearized Phillips Curve 7.1 Slope Coefficients 7.2 Error Coefficients 8 Existence Results and 8.1 Main Results 8.2 Key Proofs 8.3 Discussion 9 Bifurcation Analysis 9.1 Analytic Aspects 9.2 Algebraic Aspects (I) Singularities and Covers 9.3 Algebraic Aspects (II) Homology 9.4 Algebraic Aspects (III) Schemes 9.5 Wider Economic Interpretations 10 Econometric and Theoretical Implications and 10.1 Identification and Trade-offs 10.2 Econometric Duality 10.3 Coefficient Properties 10.4 Microeconomic Interpretation 11 Policy Rule 12 Conclusions and References Appendices A Proof of Theorem 2 and A.1 Proof of Part (i) A.2 Behaviour of ∆ A.3 Proof Part (iii) B Proofs from Section 4 and B.1 Individual Product Demand (4.2) B.2 Flexible Price Equilibrium and ZINSS (4.4) B.3 Price Dispersion (4.5) B.4 Cost Minimization (4.6) and (10.4) B.5 Consolidation (4.8) C Proofs from Section 5, and C.1 Puzzles, Policy and Persistence C.2 Extending No Persistence D Stochastic Equilibrium and D.1 Non-Stochastic Equilibrium D.2 Profits and Long-Run Growth E Slopes and Eigenvalues and E.1 Slope Coefficients E.2 Linearized DSGE Solution E.3 Eigenvalue Conditions E.4 Rouche’s Theorem Conditions F Abstract Algebra and F.1 Homology Groups F.2 Basic Categories F.3 De Rham Cohomology F.4 Marginal Costs and Inflation G Further Keynesian Models and G.1 Taylor Pricing G.2 Calvo Wage Phillips Curve G.3 Unconventional Policy Settings H Empirical Robustness and H.1 Parameter Selection H.2 Phillips Curve I Additional Evidence and I.1 Other Structural Parameters I.2 Lucas Critique I.3 Trend Inflation Volatility F Abstract Algebra This section supplies an introductory primer on homological algebra, De Rham cohomology and category theory, complimentary to the informal discussion in the text. Each occupies a subsection. At the end, a short part is devoted to additional details of a calculation from Proposition 20, which applies the methods here to the ultimate goal of the paper. F.1 Homology Groups This part develops the theory of singular homology to support the claims and analysis in the main text. Other popular homology constructions are discussed in Jacobson [1980]. Informally, the singular homology is built by a succession of mappings between n dimensional blocks and the paths around their boundaries. F.1.1 Singular Simplex its vertices are the k standard unit vectors and the origin. [112] Familiar examples include: F.1.2 Singular Chain Complex F.1.3 Homotopy Invariance for all n ≥ 0. This means that homology groups are topologically invariants. In particular, if X is a connected contractible space, then all its homology groups are 0 except I finish with a sketch of the proof of homotopy invariance of singular homology. A continuous map f : X → Y induces a homomorphism It is easy to see that where f♯ is a chain map which descends to homomorphisms on homology It is left to show that, if f and g are homotopically equivalent, then f∗ = g∗. This implies that if f is a homotopy equivalence then f∗ is an isomorphism. Let F : X × [0, 1] → Y be a homotopy, that takes f to g on the level of chains. It defines a homomorphism Therefore, they are homologous, which settles the claim. This paper is available on arxiv under CC 4.0 license. Author: (1) David Staines. Author: Author: (1) David Staines. Table of Links Abstract Abstract 1 Introduction 1 Introduction 2 Mathematical Arguments 2 Mathematical Arguments 3 Outline and Preview 3 Outline and Preview 4 Calvo Framework and 4.1 Household’s Problem 4 Calvo Framework and 4.1 Household’s Problem 4.2 Preferences 4.2 Preferences 4.3 Household Equilibrium Conditions 4.3 Household Equilibrium Conditions 4.4 Price-Setting Problem 4.4 Price-Setting Problem 4.5 Nominal Equilibrium Conditions 4.5 Nominal Equilibrium Conditions 4.6 Real Equilibrium Conditions and 4.7 Shocks 4.6 Real Equilibrium Conditions and 4.7 Shocks 4.8 Recursive Equilibrium 4.8 Recursive Equilibrium 5 Existing Solutions 5 Existing Solutions 5.1 Singular Phillips Curve 5.1 Singular Phillips Curve 5.2 Persistence and Policy Puzzles 5.2 Persistence and Policy Puzzles 5.3 Two Comparison Models 5.3 Two Comparison Models 5.4 Lucas Critique 5.4 Lucas Critique 6 Stochastic Equilibrium and 6.1 Ergodic Theory and Random Dynamical Systems 6 Stochastic Equilibrium and 6.1 Ergodic Theory and Random Dynamical Systems 6.2 Equilibrium Construction 6.2 Equilibrium Construction 6.3 Literature Comparison 6.3 Literature Comparison 6.4 Equilibrium Analysis 6.4 Equilibrium Analysis 7 General Linearized Phillips Curve 7 General Linearized Phillips Curve 7.1 Slope Coefficients 7.1 Slope Coefficients 7.2 Error Coefficients 7.2 Error Coefficients 8 Existence Results and 8.1 Main Results 8 Existence Results and 8.1 Main Results 8.2 Key Proofs 8.2 Key Proofs 8.3 Discussion 8.3 Discussion 9 Bifurcation Analysis 9 Bifurcation Analysis 9.1 Analytic Aspects 9.1 Analytic Aspects 9.2 Algebraic Aspects (I) Singularities and Covers 9.2 Algebraic Aspects (I) Singularities and Covers 9.3 Algebraic Aspects (II) Homology 9.3 Algebraic Aspects (II) Homology 9.4 Algebraic Aspects (III) Schemes 9.4 Algebraic Aspects (III) Schemes 9.5 Wider Economic Interpretations 9.5 Wider Economic Interpretations 10 Econometric and Theoretical Implications and 10.1 Identification and Trade-offs 10 Econometric and Theoretical Implications and 10.1 Identification and Trade-offs 10.2 Econometric Duality 10.2 Econometric Duality 10.3 Coefficient Properties 10.3 Coefficient Properties 10.4 Microeconomic Interpretation 10.4 Microeconomic Interpretation 11 Policy Rule 11 Policy Rule 12 Conclusions and References 12 Conclusions and References Appendices Appendices A Proof of Theorem 2 and A.1 Proof of Part (i) A Proof of Theorem 2 and A.1 Proof of Part (i) A.2 Behaviour of ∆ A.2 Behaviour of ∆ A.3 Proof Part (iii) A.3 Proof Part (iii) B Proofs from Section 4 and B.1 Individual Product Demand (4.2) B Proofs from Section 4 and B.1 Individual Product Demand (4.2) B.2 Flexible Price Equilibrium and ZINSS (4.4) B.2 Flexible Price Equilibrium and ZINSS (4.4) B.3 Price Dispersion (4.5) B.3 Price Dispersion (4.5) B.4 Cost Minimization (4.6) and (10.4) B.4 Cost Minimization (4.6) and (10.4) B.5 Consolidation (4.8) B.5 Consolidation (4.8) C Proofs from Section 5, and C.1 Puzzles, Policy and Persistence C Proofs from Section 5, and C.1 Puzzles, Policy and Persistence C.2 Extending No Persistence C.2 Extending No Persistence D Stochastic Equilibrium and D.1 Non-Stochastic Equilibrium D Stochastic Equilibrium and D.1 Non-Stochastic Equilibrium D.2 Profits and Long-Run Growth D.2 Profits and Long-Run Growth E Slopes and Eigenvalues and E.1 Slope Coefficients E Slopes and Eigenvalues and E.1 Slope Coefficients E.2 Linearized DSGE Solution E.2 Linearized DSGE Solution E.3 Eigenvalue Conditions E.3 Eigenvalue Conditions E.4 Rouche’s Theorem Conditions E.4 Rouche’s Theorem Conditions F Abstract Algebra and F.1 Homology Groups F Abstract Algebra and F.1 Homology Groups F.2 Basic Categories F.2 Basic Categories F.3 De Rham Cohomology F.3 De Rham Cohomology F.4 Marginal Costs and Inflation F.4 Marginal Costs and Inflation G Further Keynesian Models and G.1 Taylor Pricing G Further Keynesian Models and G.1 Taylor Pricing G.2 Calvo Wage Phillips Curve G.2 Calvo Wage Phillips Curve G.3 Unconventional Policy Settings G.3 Unconventional Policy Settings H Empirical Robustness and H.1 Parameter Selection H Empirical Robustness and H.1 Parameter Selection H.2 Phillips Curve H.2 Phillips Curve I Additional Evidence and I.1 Other Structural Parameters I Additional Evidence and I.1 Other Structural Parameters I.2 Lucas Critique I.2 Lucas Critique I.3 Trend Inflation Volatility I.3 Trend Inflation Volatility F Abstract Algebra This section supplies an introductory primer on homological algebra, De Rham cohomology and category theory, complimentary to the informal discussion in the text. Each occupies a subsection. At the end, a short part is devoted to additional details of a calculation from Proposition 20, which applies the methods here to the ultimate goal of the paper. F.1 Homology Groups This part develops the theory of singular homology to support the claims and analysis in the main text. Other popular homology constructions are discussed in Jacobson [1980]. Informally, the singular homology is built by a succession of mappings between n dimensional blocks and the paths around their boundaries. F.1.1 Singular Simplex F.1.1 Singular Simplex its vertices are the k standard unit vectors and the origin. [112] Familiar examples include: F.1.2 Singular Chain Complex F.1.2 Singular Chain Complex F.1.3 Homotopy Invariance F.1.3 Homotopy Invariance for all n ≥ 0. This means that homology groups are topologically invariants. In particular, if X is a connected contractible space, then all its homology groups are 0 except I finish with a sketch of the proof of homotopy invariance of singular homology. A continuous map f : X → Y induces a homomorphism It is easy to see that where f♯ is a chain map which descends to homomorphisms on homology It is left to show that, if f and g are homotopically equivalent, then f∗ = g∗. This implies that if f is a homotopy equivalence then f∗ is an isomorphism. Let F : X × [0, 1] → Y be a homotopy, that takes f to g on the level of chains. It defines a homomorphism Therefore, they are homologous, which settles the claim. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

A Beginner's Guide to Homology

Most of us have interacted with large language models (LLMs) like GPT-4, and they have been impressive. However, you might have wondered: What if I want to give my personal data or a lengthy document to an AI and extract specific information from it? In this blog post, we’ll explore: Problems with traditional LLMs
What is Retrieval-Augmented Generation (RAG)?
How RAG works
Real-world implementations of RAG https://youtu.be/zW1ELMo7D5A?embedable=true Problems With Traditional LLMs While LLMs have revolutionized the way we interact with technology, they come with some significant limitations: Hallucination: LLMs sometimes hallucinate, meaning they provide factually incorrect answers. This occurs because they generate responses based on patterns in the data they were trained on, not always on verified facts. Example: An AI might state that a historical event occurred in a year when it didn’t. Outdated Knowledge: Models like GPT-4 have a knowledge cutoff date (e.g., May 2024). They lack information on events or developments that occurred after this date. Implication: The AI cannot provide insights on recent advancements, news, or data. Untraceable Reasoning: LLMs often provide answers without clear sources, leading to untraceable reasoning. Transparency: Users don’t know where the information came from. Bias: The training data may contain biases, affecting the output. Accountability: Difficult to verify the accuracy of the response. Lack of Domain-Specific Expertise: While LLMs are good at generating general responses, they often lack domain-specific expertise.


Outcome: Answers may be generic and not delve deep into specialized topics. What Is RAG? Imagine RAG as your personal assistant who can memorize thousands of pages of documents. You can later query this assistant to extract any information you need. RAG stands for Retrieval-Augmented Generation, where: Retrieval: Fetches information from a database. Augmentation: Combines the retrieved information with the user’s prompt. Generation: Produces the final answer using an LLM. How RAG Works The Traditional Method vs. RAG Traditional LLM Approach: A user asks a question. The LLM generates an answer based solely on its trained knowledge base. If the question is outside its knowledge base, it may provide incorrect or generic answers. RAG Approach: Document Ingestion: A document is broken down into smaller chunks. These chunks are converted into embeddings (vector representations). The embeddings are indexed and stored in a vector database. 2. Query Processing: The user asks a question. The question is converted into an embedding using the same model. A search engine queries the vector database to find the most relevant chunks. The top relevant results are retrieved. 3. Answer Generation: The retrieved information and the user’s question are combined. This combined input is passed to the LLM (like GPT-4 or LLaMA). The LLM generates a context-aware answer. The answer is returned to the user. Real-World Implementations of RAG General knowledge Retrieval: Input extensive documents (hundreds or thousands of pages). Efficiently extract specific information when needed. Customer Support: RAG-powered chatbots can access real-time customer data. Provide accurate and personalized responses in sectors like finance, banking, or telecom. Improved first-response rates lead to higher customer satisfaction and loyalty. Legal Sector: Assist in contract analysis, e-discoveries, or regulatory compliances. Streamline legal research and document review processes. As Thomas Edison once said: “Vision without execution is hallucination.” In the context of AI: “LLMs without RAG are hallucination.” By integrating RAG, we can overcome many limitations of traditional LLMs, providing more accurate, up-to-date, and domain-specific answers. In upcoming posts, we’ll explore more advanced topics on RAG and how to obtain even more relevant responses from it. Stay tuned! Thank you for reading! Most of us have interacted with large language models (LLMs) like GPT-4, and they have been impressive. However, you might have wondered: What if I want to give my personal data or a lengthy document to an AI and extract specific information from it? What if I want to give my personal data or a lengthy document to an AI and extract specific information from it? In this blog post, we’ll explore: Problems with traditional LLMs What is Retrieval-Augmented Generation (RAG)? How RAG works Real-world implementations of RAG Problems with traditional LLMs What is Retrieval-Augmented Generation (RAG)? How RAG works Real-world implementations of RAG https://youtu.be/zW1ELMo7D5A?embedable=true https://youtu.be/zW1ELMo7D5A?embedable=true Problems With Traditional LLMs While LLMs have revolutionized the way we interact with technology, they come with some significant limitations: Hallucination: LLMs sometimes hallucinate, meaning they provide factually incorrect answers. This occurs because they generate responses based on patterns in the data they were trained on, not always on verified facts. Example: An AI might state that a historical event occurred in a year when it didn’t. Hallucination: LLMs sometimes hallucinate, meaning they provide factually incorrect answers. This occurs because they generate responses based on patterns in the data they were trained on, not always on verified facts. Example: An AI might state that a historical event occurred in a year when it didn’t. Hallucination: Outdated Knowledge: Models like GPT-4 have a knowledge cutoff date (e.g., May 2024). They lack information on events or developments that occurred after this date. Implication: The AI cannot provide insights on recent advancements, news, or data. Outdated Knowledge: Models like GPT-4 have a knowledge cutoff date (e.g., May 2024). They lack information on events or developments that occurred after this date. Implication : The AI cannot provide insights on recent advancements, news, or data. Outdated Knowledge: knowledge cutoff date Implication Untraceable Reasoning: LLMs often provide answers without clear sources, leading to untraceable reasoning. Transparency: Users don’t know where the information came from. Bias: The training data may contain biases, affecting the output. Accountability: Difficult to verify the accuracy of the response. Untraceable Reasoning: LLMs often provide answers without clear sources, leading to untraceable reasoning . Transparency : Users don’t know where the information came from. Bias : The training data may contain biases, affecting the output. Accountability : Difficult to verify the accuracy of the response. Untraceable Reasoning: untraceable reasoning Transparency Bias Accountability Lack of Domain-Specific Expertise: While LLMs are good at generating general responses, they often lack domain-specific expertise. Outcome: Answers may be generic and not delve deep into specialized topics. Lack of Domain-Specific Expertise: While LLMs are good at generating general responses, they often lack domain-specific expertise. Lack of Domain-Specific Expertise: While LLMs are good at generating general responses, they often lack domain-specific expertise . Lack of Domain-Specific Expertise: domain-specific expertise Outcome: Answers may be generic and not delve deep into specialized topics. Outcome : Answers may be generic and not delve deep into specialized topics. Outcome generic What Is RAG? Imagine RAG as your personal assistant who can memorize thousands of pages of documents. You can later query this assistant to extract any information you need. RAG stands for Retrieval-Augmented Generation , where: RAG stands for Retrieval-Augmented Generation Retrieval: Fetches information from a database. Retrieval : Fetches information from a database. Retrieval Augmentation: Combines the retrieved information with the user’s prompt. Augmentation : Combines the retrieved information with the user’s prompt. Augmentation Generation: Produces the final answer using an LLM. Generation : Produces the final answer using an LLM. Generation How RAG Works The Traditional Method vs. RAG Traditional LLM Approach: Traditional LLM Approach: A user asks a question. A user asks a question. The LLM generates an answer based solely on its trained knowledge base. The LLM generates an answer based solely on its trained knowledge base. If the question is outside its knowledge base, it may provide incorrect or generic answers. If the question is outside its knowledge base, it may provide incorrect or generic answers. RAG Approach: RAG Approach: Document Ingestion: Document Ingestion: Document Ingestion: A document is broken down into smaller chunks. A document is broken down into smaller chunks. These chunks are converted into embeddings (vector representations). These chunks are converted into embeddings (vector representations). The embeddings are indexed and stored in a vector database. The embeddings are indexed and stored in a vector database . vector database 2. Query Processing: 2. Query Processing: The user asks a question. The user asks a question. The question is converted into an embedding using the same model. The question is converted into an embedding using the same model. A search engine queries the vector database to find the most relevant chunks. A search engine queries the vector database to find the most relevant chunks. The top relevant results are retrieved. The top relevant results are retrieved. 3. Answer Generation: 3. Answer Generation: The retrieved information and the user’s question are combined. The retrieved information and the user’s question are combined. This combined input is passed to the LLM (like GPT-4 or LLaMA). This combined input is passed to the LLM (like GPT-4 or LLaMA). The LLM generates a context-aware answer. The LLM generates a context-aware answer. The answer is returned to the user. The answer is returned to the user. Real-World Implementations of RAG General knowledge Retrieval: General knowledge Retrieval: Input extensive documents (hundreds or thousands of pages). Input extensive documents (hundreds or thousands of pages). Efficiently extract specific information when needed. Efficiently extract specific information when needed. Customer Support: Customer Support: RAG-powered chatbots can access real-time customer data. RAG-powered chatbots can access real-time customer data. Provide accurate and personalized responses in sectors like finance, banking, or telecom. Provide accurate and personalized responses in sectors like finance, banking, or telecom. Improved first-response rates lead to higher customer satisfaction and loyalty. Improved first-response rates lead to higher customer satisfaction and loyalty. Legal Sector: Legal Sector: Assist in contract analysis, e-discoveries, or regulatory compliances. Assist in contract analysis, e-discoveries, or regulatory compliances. Streamline legal research and document review processes. Streamline legal research and document review processes. As Thomas Edison once said: “Vision without execution is hallucination.” “Vision without execution is hallucination.” “Vision without execution is hallucination.” “Vision without execution is hallucination.” In the context of AI: “LLMs without RAG are hallucination.” “LLMs without RAG are hallucination.” “LLMs without RAG are hallucination.” “LLMs without RAG are hallucination.” By integrating RAG, we can overcome many limitations of traditional LLMs, providing more accurate, up-to-date, and domain-specific answers. In upcoming posts, we’ll explore more advanced topics on RAG and how to obtain even more relevant responses from it. Stay tuned! In upcoming posts, we’ll explore more advanced topics on RAG and how to obtain even more relevant responses from it. Stay tuned! Thank you for reading!

RAG: An Introduction for Beginners

Playwright and Chrome Browser Testing in Heroku: A Beginner's Guide

Heroku ukan dramaturgo ukat Chrome Navegador ukan yant’awipa: Qalltirinakatakix mä guia

Heroku-da dramaturq və Chrome Brauzer Testi: Başlayanlar üçün Bələdçi

Testiranje dramaturga i Chrome pretraživača u Heroku: Vodič za početnike

Pruebas del navegador Chrome y Playwright en Heroku: una guía para principiantes

Tès otè ak navigatè Chrome nan Heroku: Gid pou yon debutan

Heroku での Playwright と Chrome ブラウザのテスト: 初心者向けガイド

Тестирање на драматург и на прелистувачот Chrome во Heroku: водич за почетници

Penulis drama dan Ujian Penyemak Imbas Chrome dalam Heroku: Panduan Pemula

Testimi i dramaturgut dhe i shfletuesit Chrome në Heroku: Një udhëzues fillestar

Jaribio la Playwright na Kivinjari cha Chrome katika Heroku: Mwongozo wa Wanaoanza

การทดสอบนักเขียนบทละครและเบราว์เซอร์ Chrome ใน Heroku: คู่มือสำหรับผู้เริ่มต้น

Dramaturg va Chrome brauzerini Heroku’da sinovdan o‘tkazish: yangi boshlanuvchilar uchun qo‘llanma

RunLoops impact on asynchronous tasks I am Boris Dobretsov, and some time ago I published my first article - Understanding Parallel Programming: A Guide for Beginners. https://hackernoon.com/understanding-parallel-programming-a-guide-for-beginners?embedable=true In that article, I introduced basic concepts such as "processes" and "threads" and explained in simple terms what a processor, operating system, process, and thread are. Today, we will elaborate further on RunLoops and their impact on asynchronous tasks. But first, let's refresh our knowledge of what a RunLoop is and what it is responsible for. A RunLoop helps asynchronous tasks run at the right time without blocking or interfering with the main thread. It functions as a cycle of event handling, used to schedule tasks and coordinate incoming events. Its purpose is to keep the thread active when there is work to do and put it to sleep when there is none. As we know from the previous article, there are several main types of architecture for code organization: Synchronous single-threaded


Asynchronous single-threaded


Synchronous multi-threaded


Asynchronous multi-threaded Some of these are simpler, while others are designed to run several tasks (competing tasks) at the same time, making the development process more efficient and multifunctional. The most commonly used architecture in iOS application development is the asynchronous multi-threaded model. It is important to understand how to interact with these models and what to do to prevent overloading. That is why in this article we are going to discuss RunLoops impact on asynchronous tasks. As we also know from the previous article, asynchronous tasks can be paused mid-execution and resumed later. But who decides when to put a task on hold and when to resume it? It’s actually the task itself that makes this decision. This is because asynchronous tasks consist of two parts: the first starts the task, and the second executes asynchronously in response to a specific event. The latter part is added to a source for the RunLoop and is checked on each loop iteration. If the specified event occurs, the task proceeds. A basic example of an asynchronous task is a timer. Let me share the code which which demonstrates this idea: Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print("tick")
} In the above example, you can see the code which starts a timer that runs every quarter of a second, outputting "tick" to the console. The first part of the asynchronous task is creating the timer, and the second part is passing the block to the scheduled Timer method. The task is single-threaded: both the timer setup and block execution happen in the same thread. However, it is asynchronous since the block doesn’t execute immediately but after a delay that allows the thread to do other work in the meantime. This illustrates the interconnection between asynchronous tasks and the RunLoop. The timer block will be called every quarter second, with the RunLoop responsible for this condition. However, if the thread is busy with a long-running task and the iteration cannot be completed within 0.25 seconds, the timer's block will be delayed. Let's modify the example so that the block outputs the current time: Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print(Date())
} Let’s see what will be the console output: 2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000 In this case,  the timer goes off four times per second. Let's now add another asynchronous task that runs once every second and takes up the thread by waiting to be executed: Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print(Date())
}

Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { timer in    
  sleep(1)
} Console output: 2017-09-26 05:17:33 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:35 +0000
2017-09-26 05:17:35 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:37 +0000
2017-09-26 05:17:37 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:39 +0000
2017-09-26 05:17:39 +0000
2017-09-26 05:17:40 +0000
2017-09-26 05:17:40 +0000 As you can see, the timer now triggers at irregular intervals, sometimes twice, sometimes three times per second. This happened because the thread was too busy running other code to process the timer in time. This example perfectly illustrates that there is no magic in asynchronous code. It relies on the RunLoop and competes with other tasks in the thread. My advice is: don’t rely on miracles when planning asynchronous tasks; consider whether they can be executed on time. If there is a likelihood that thread resources may be insufficient to run all tasks, consider offloading tasks to separate threads where they won’t face interference. Conclusion In the next article, we will talk about the main approaches to building multi-threaded code in iOS and will touch upon the concepts of Thread, Grand Central Dispatch (GCD), and Operation. Stay tuned! RunLoops impact on asynchronous tasks I am Boris Dobretsov, and some time ago I published my first article - Understanding Parallel Programming: A Guide for Beginners. Understanding Parallel Programming: A Guide for Beginners . Understanding Parallel Programming: A Guide for Beginners https://hackernoon.com/understanding-parallel-programming-a-guide-for-beginners?embedable=true https://hackernoon.com/understanding-parallel-programming-a-guide-for-beginners?embedable=true In that article, I introduced basic concepts such as " processes " and " threads " and explained in simple terms what a processor, operating system, process, and thread are. processes threads Today, we will elaborate further on RunLoops and their impact on asynchronous tasks. RunLoops But first, let's refresh our knowledge of what a RunLoop is and what it is responsible for. RunLoop A RunLoop helps asynchronous tasks run at the right time without blocking or interfering with the main thread. It functions as a cycle of event handling, used to schedule tasks and coordinate incoming events. Its purpose is to keep the thread active when there is work to do and put it to sleep when there is none. A RunLoop helps asynchronous tasks run at the right time without blocking or interfering with the main thread. It functions as a cycle of event handling, used to schedule tasks and coordinate incoming events. Its purpose is to keep the thread active when there is work to do and put it to sleep when there is none. RunLoop As we know from the previous article, there are several main types of architecture for code organization: Synchronous single-threaded Asynchronous single-threaded Synchronous multi-threaded Asynchronous multi-threaded Synchronous single-threaded Synchronous single-threaded Synchronous single-threaded Asynchronous single-threaded Asynchronous single-threaded Asynchronous single-threaded Synchronous multi-threaded Synchronous multi-threaded Synchronous multi-threaded Asynchronous multi-threaded Asynchronous multi-threaded Asynchronous multi-threaded Some of these are simpler, while others are designed to run several tasks (competing tasks) at the same time, making the development process more efficient and multifunctional. The most commonly used architecture in iOS application development is the asynchronous multi-threaded model . It is important to understand how to interact with these models and what to do to prevent overloading. That is why in this article we are going to discuss RunLoops impact on asynchronous tasks . asynchronous multi-threaded model RunLoops impact on asynchronous tasks As we also know from the previous article, asynchronous tasks can be paused mid-execution and resumed later. But who decides when to put a task on hold and when to resume it? But who decides when to put a task on hold and when to resume it? It’s actually the task itself that makes this decision. This is because asynchronous tasks consist of two parts: the first starts the task, and the second executes asynchronously in response to a specific event. The latter part is added to a source for the RunLoop and is checked on each loop iteration. If the specified event occurs, the task proceeds. A basic example of an asynchronous task is a timer . Let me share the code which which demonstrates this idea: timer Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print("tick")
} Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print("tick")
} In the above example, you can see the code which starts a timer that runs every quarter of a second, outputting "tick" to the console. The first part of the asynchronous task is creating the timer, and the second part is passing the block to the scheduled Timer method. The task is single-threaded: both the timer setup and block execution happen in the same thread. However, it is asynchronous since the block doesn’t execute immediately but after a delay that allows the thread to do other work in the meantime. This illustrates the interconnection between asynchronous tasks and the RunLoop. The timer block will be called every quarter second, with the RunLoop responsible for this condition. However, if the thread is busy with a long-running task and the iteration cannot be completed within 0.25 seconds, the timer's block will be delayed. Let's modify the example so that the block outputs the current time: Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print(Date())
} Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print(Date())
} Let’s see what will be the console output: 2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000 2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:16 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:17 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000
2017-09-26 05:13:18 +0000 In this case,  the timer goes off four times per second. Let's now add another asynchronous task that runs once every second and takes up the thread by waiting to be executed: Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print(Date())
}

Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { timer in    
  sleep(1)
} Timer.scheduledTimer(withTimeInterval: 0.25, repeats: true) { timer in    
  print(Date())
}

Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { timer in    
  sleep(1)
} Console output: 2017-09-26 05:17:33 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:35 +0000
2017-09-26 05:17:35 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:37 +0000
2017-09-26 05:17:37 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:39 +0000
2017-09-26 05:17:39 +0000
2017-09-26 05:17:40 +0000
2017-09-26 05:17:40 +0000 2017-09-26 05:17:33 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:34 +0000
2017-09-26 05:17:35 +0000
2017-09-26 05:17:35 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:36 +0000
2017-09-26 05:17:37 +0000
2017-09-26 05:17:37 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:38 +0000
2017-09-26 05:17:39 +0000
2017-09-26 05:17:39 +0000
2017-09-26 05:17:40 +0000
2017-09-26 05:17:40 +0000 As you can see, the timer now triggers at irregular intervals, sometimes twice, sometimes three times per second. This happened because the thread was too busy running other code to process the timer in time. This example perfectly illustrates that there is no magic in asynchronous code. It relies on the RunLoop and competes with other tasks in the thread. My advice is: don’t rely on miracles when planning asynchronous tasks; consider whether they can be executed on time. If there is a likelihood that thread resources may be insufficient to run all tasks, consider offloading tasks to separate threads where they won’t face interference. Conclusion In the next article, we will talk about the main approaches to building multi-threaded code in iOS and will touch upon the concepts of Thread , Grand Central Dispatch (GCD) , and Operation . Stay tuned! Thread Grand Central Dispatch (GCD) Operation

BEGIN

begin.ai

-- employees

Since n.d.

COMPANY RANKING

BEGIN

EVERGREEN INDEX #3743

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

Begin WIKI

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

BEGIN

begin.ai

-- employees

Since n.d.

COMPANY RANKING

BEGIN

EVERGREEN INDEX #3743

RELATED COMPANIESRANK

STORIES ABOUT BEGIN

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

Begin WIKI

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