We are a leading Fintech Development Services company. We provide services to clients for Enterprise Cloud Solutions, Fintech Services, De-fi Development, Money Management Solutions, Blockchain Solutions, Trading Bots, Decentralised Applications, Financial Analytics, Design, Motion Animation, Web and Mobile Solutions, APIs, bots, software solutions, and more.

Stackera

stackera

Setup, Run and Debug Cypress Tests: A Quick Guide To Get You Started

HackerNoon COO and CEO Discuss Entrepreneurship, Working With Your Spouse, and More

Introduction is a foundational class in UIKit and . Everything we see on the screen is constructed from `s and their subclasses. UIView iOS development UIView One topic often considered basic is the geometry of . It's easy to grasp initially, but complete understanding is often elusive, even for very experienced iOS engineers. In this article, we will dive deeply into the world of geometry. We will explain the main concepts, such as , , , , , how they relate to each other, and answer more advanced questions about computing the and Autolayout specifics. UIView UIView frame bounds center anchorPoint transform frame Playground To better understand the geometry, I've also developed a small iOS app: . https://github.com/psharanda/UIViewGeometry In the app, you can experiment with different properties in real time by adjusting sliders. Such an interactive approach is really helpful for grasping the nuances. UIView frame The definition of in Apple documentation is: UIView.frame The frame rectangle, which describes the view’s location and size in its superview’s coordinate system. Most of the time, we operate just with frames, either during manual layout or when printing the view's debug description. The designated initializer for also uses the frame as the only param. UIView This seems simple and straightforward. However, the reality is more complex. The frame is actually a computed property of . It is not the definitive source of the view's geometry. So, what is it exactly? UIView bounds Apparently, has many more properties related to geometry, and we’re now going to check the real, non-computed ones. Let’s examine the first of them: . UIView bounds The definition of is: UIView.bounds The bounds rectangle, which describes the view’s location and size in its own coordinate system. Usually, both and are simply equal to , and is the same as (however, it is not always true). bounds.origin.x bounds.origin.y 0.0 bounds.size frame.size What happens if is not equal to ? In that case, bounds basically act as a viewport, defining which part of the view coordinate system is visible to the outside world (superview). can also be seen as an additional translation (with a minus sign) for all subviews and view’s content rendered using . bounds.origin .zero bounds.origin drawRect This might remind you of . It is for a reason: the property of a is directly linked to its . UIScrollView contentOffset UIScrollView bounds.origin It's important to note that border, background, and shadow are rendered without considering . bounds.origin Previously, we mentioned that sometimes cannot be equal to . It may happen if transform is not equal to . frame.size bounds.size .identity According to the documentation, setting to any value when is not is considered undefined behavior (getting is still fine). However, setting when is not is valid.  In that case, describes the rectangle that fits the view after all transformations in its superview’s coordinate system. frame transform .identity bounds transform .identity frame center The definition of : UIView.center The center point of the view's frame rectangle in its superview’s coordinate system. However, the term "center" can be a bit misleading. It only represents the actual center of the view if the (more on this in the next section) is positioned at the center, specifically at ( , ). A more accurate definition for would be: view.anchorPoint 0.5 0.5 center The coordinates of the view’s anchor point in its superview’s coordinate system. UIView’s is exactly the same as . center CALayer.position The combination of and can fully replace the use of bounds center frame transform The transform property in iOS development is a fundamental concept that enables developers to apply geometric transformations to views. UIView The transform property of is of the type , which represents a matrix used for affine transformations. Affine transformations include: UIView CGAffineTransform Translation To move a view, you set the transform property with . For instance, moves the view 50 points to the right and 75 points down. CGAffineTransform(translationX:y:) view.transform = CGAffineTransform(translationX: 50, y: 75) Scaling To scale a view, use . For example, halves the size of the view in both width and height. CGAffineTransform(scaleX:y:) view.transform = CGAffineTransform(scaleX: 0.5, y: 0.5) Rotation To rotate a view, apply . The angle is in radians, so to rotate 30 degrees, you would use . CGAffineTransform(rotationAngle:) view.transform = CGAffineTransform(rotationAngle: .pi / 6) Combining Transforms One of the powerful aspects of the transform property is the ability to combine transformations. You can combine scaling, rotation, and translation into a single transform using concatenation, for example: var t = CGAffineTransform.identity // 0
t = t.concatenating(CGAffineTransform(scaleX: 0.5, y: 0.5)) //1
t = t.concatenating(CGAffineTransform(rotationAngle: .pi / 6)) //2
t = t.concatenating(CGAffineTransform(translationX: 50, y: 150)) //3
view.transform = t To reset a transformation, set the property to , which is also the default for a newly created . transform CGAffineTransform.identity UIView Perspective ’s transform is baked by which has the type and can be used for even more advanced transformations like changing the perspective UIView CALayer.transform CATransform3D var transform = CATransform3DIdentity;
transform.m34 = 1.0 / 500.0;
view.layer.transform = CATransform3DRotate(transform, .pi / 4, 0, 1, 0) anchorPoint The anchor point defines how a view behaves during transformations. It's specified using the unit coordinate space, where ( , ) is the top-left corner of the view's bounds rectangle, and ( , ) is the bottom-right corner. By default, the anchor point of a is set to ( , ), which is the center of the view’s bounds rectangle. 0 0 1 1 UIView 0.5 0.5 Interestingly, the property was only added to in iOS 16, but it has always been accessible through . anchorPoint UIView view.layer.anchorPoint Geometric manipulations, like rotation or scaling, occur around the anchor point. For example, if you apply a rotation transform to a view with the default anchor point, the view will rotate around its center. If you change the anchor point to a different location, the view will rotate around this new point. How to calculate the frame? We mentioned in the beginning that is a computed property. Now, with enough knowledge, let’s compile all the observations into actual code that computes the frame. frame First, let’s follow the positioning logic that is used during the render process. We start with a rectangle, with set to and set to . is not involved in calculations since it only affects subviews and the output. origin .zero size bounds.size bounds.origin drawRect Before applying the transform, we must translate the view according to its . We apply the transform only when the view, with its , is aligned with the starting point coordinates ( , ). anchorPoint anchorPoint 0 0 Now, we can apply the transform. The last step is to translate the view by its value, positioning it correctly. center These transformations can be concatenated into a single transform (i.e., absolute one), which is then applied to zero-origin bounds by using function. CGRectApplyAffineTransform Here is the final function which computes the frame: func computeFrame(bounds: CGRect,
                  center: CGPoint,
                  anchorPoint: CGPoint,
                  tranform: CGAffineTransform) -> CGRect {

    // set the initial rectangle to bounds with origin set to (0, 0)
    let zeroOriginBounds = CGRect(origin: .zero, size: bounds.size) // 1

    // combine transformations
    let absoluteTransform = CGAffineTransform(
            translationX: -anchorPoint.x * bounds.width,
            y: -anchorPoint.y * bounds.height
        ) // 2
        .concatenating(tranform) // 3
        .concatenating(CGAffineTransform(translationX: center.x, y: center.y)) // 4

    // apply transform to the initial rectangle
    return CGRectApplyAffineTransform(zeroOriginBounds, absoluteTransform)
} How can this knowledge be useful for us? Apart from just satisfying curiosity and gaining a better understanding of the internals, this algorithm has some real-world applications. A classic example is an image editor. Imagine you are building an application that creates custom stories. You want to place stickers on top of a photo, move, scale, and rotate them with your finger. For the editing mode, you use the actual and layout it by modifying its properties like center, bounds, and transform. Eventually, you’d like to render your story project into a bitmap and share it in high resolution, and that’s where understanding how geometry works becomes really useful. The image rendering code can look like the following: UIImageView UIView let renderer = UIGraphicsImageRenderer(size: imageSize)
let image = renderer.image { context in
    let cgContext = context.cgContext
    // render photo…
    // render other things…
    
    // render our sticker
    let absoluteTransform = CGAffineTransform(
        translationX: -sticker.anchorPoint.x * sticker.bounds.width,
        y: -sticker.anchorPoint.y * sticker.bounds.height
    )
        .concatenating(sticker.transform)
        .concatenating(
            CGAffineTransform(translationX: sticker.center.x, y: sticker.center.y)
        )
    
    cgContext.saveGState()
    cgContext.concatenate(absoluteTransform)
    sticker.image.draw(in: CGRect(origin: .zero, size: sticker.bounds.size))
    cgContext.restoreGState()
} What about Autolayout? Autolayout doesn't work with . It also ignores the and properties during its calculations. For each view, Autolayout calculates and sets only the and . The and are still used, but only for the final render on screen, and are applied afterward. frame transform anchorPoint bounds center transform anchorPoint To reiterate, in the Autolayout world, , , and don't exist. The Autolayout process is: constraints in, and out. frame transform anchorPoint bounds center Additional Resources UIView Documentation – https://developer.apple.com/documentation/uikit/uiview View Programming Guide – https://developer.apple.com/library/archive/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/WindowsandViews/WindowsandViews.html#//apple_ref/doc/uid/TP40009503-CH2-SW5 Core Animation Basics – https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreAnimation_guide/CoreAnimationBasics/CoreAnimationBasics.html#//apple_ref/doc/uid/TP40004514-CH2-SW3 Understanding UIKit Rendering – https://www.wwdcnotes.com/notes/wwdc11/121/ Understanding UIKit: CALayer Anchor Point – https://ikyle.me/blog/2022/understanding-uikit-calayer-anchor-point Understanding UIScrollView – https://oleb.net/blog/2014/04/understanding-uiscrollview/

Mastering UIView Geometry: A Dive into UIKit's Foundational Class and Geometry Concepts for iOS

Crypto’s largest exchange just got hit with $4 billion in fines. Its CEO resigned. Rumors are swirling that the largest stablecoin, a crypto version of the US dollar, will collapse under US regulatory scrutiny. Every major US crypto entity is getting sued by investors, users, or the US government. Bitcoin’s price is up 126% this year. The bear market warriors claim validation. The OGs chant “victory!” The bull market champions call for new all-time highs. They all expect crypto will go on an amazing run, they just can’t agree whether that means bitcoin’s price will hit $60,000 before the halving, deliver diminishing returns through the end of 2025, peak sooner than expected in a “left-translated cycle,” or reach some other number on a timeframe that fits within the cycle theories, trading charts, and data models. Torn between two lovers Nobody else seems to believe them. Mainstream commentators seem doubtful. Jim Cramer said crypto’s done. YouTube traders say this is the “B” wave of an A-B-C correction to $6,000 (whatever that means). Your favorite regulators say it’s a fraud. Munger and Buffett say its going to zero. Macro guys tell you the wheels are about to fall off the world’s economy but 2022’s Recessionistas tell you that the recession’s been called off. On-chain gurus say prices have to go up because 75% of bitcoin’s supply sits in the hands of people who either don't care enough to sell or care so much they won’t sell. Data guys say that can’t happen, “the maths” don’t work out. One side of YouTube says the bull market’s confirmed. The other side says prices have to go down because “there is no liquidity,” “interest rates are too high,” and “we need capitulation first.” You're torn between two lovers, a bull and a bear. They both want what’s best for you, but only one is right! Just go along with it Some people simply can’t accept the reality: if bitcoin’s price stays above $15,600, crypto’s been in a bull market for over a year. If that’s you, no worries! What you’re feeling is normal during the disbelief stage of the market cycle, just before hope returns. This is a psychological phenomenon best illustrated by the Wall Street Cheat Sheet, an image that captures the emotions you will feel as you ride the crypto rollercoaster. Take a look: Can you apply that to bitcoin’s price chart? Here it is: You don’t have to believe what you see. You may, however, want to suspend your disbelief. Excuses, excuses Since the start of the year, every upswing has ended with a downswing. You get your hopes up, only to be let down. Priya in the Park insists the end is near, and she’s called every crypto bear market—sometimes more than three years in advance! She’s always right! Billy the Neighbor just bought back the Tesla stock he sold at the 2022 bottom but he’s not hitting you up for altcoin recommendations anymore crypto because “it’s dead” and “I don’t see why it’s valuable.” Your family thinks you lost all of your money. Conspiracy theorists tell you Tether, HTX, and [fill-in-the-blank crypto entity] will collapse from regulators, insolvency, central banks, law enforcement, quantum computers, and whatever else the social media algorithms slip into their feeds. Insolvent exchanges are dumping their customers’ cryptos to raise money. Think of all the excuses you’ve had to keep money out of crypto this year. Curve.Fi gets hacked and seems on the verge of imploding DeFi, so you keep your money out of the market. Death crosses and bull market support bands say you can't buy yet. You haven’t found a narrative that will bring new money into crypto, let alone a narrative that fits what you’re looking for, so you sit on your hands waiting for the altcoin capitulation or some news to get you hyped up again. China has an economic crisis. Supposedly, Europe’s in the middle of one (they don’t know it yet). Canada’s about to collapse. As a result, your mind simply can’t convince you that this market could ever recover. Yet, crypto goes up. Embrace uncertainty You think crypto should collapse, but nothing’s collapsing. Regulators seem to lose or settle every anti-crypto case. Wall Street’s preparing to take over the space. Crypto is not going away. Circumstantial evidence and on-chain behavior suggest stackers and HODLers have settled in for the long haul, and they control the largest portion of the market since 2016. Key sentiment indicators remain in a healthy equilibrium. Key metrics show strong market conditions. China’s stimulus has started to enter the market. Other Asian countries have taken back market share from the US. I could give you a dozen charts that make the future seem hopeless. https://twitter.com/MarkHelfman/status/1705780363040010437?embedable=true Despite all the gloom, the crypto market has turned a corner on every conceivable metric I look at. Bitcoin’s returns beat almost every asset that people like you and me can buy. Hard to believe, I know. Don’t try to believe it. Just try to suspend your disbelief. If you do that, maybe you’ll see a reality you never knew about. This post is also available as a collectible NFT at . https://mirror.xyz https://mirror.xyz/0x9a6600c7B40801dda9A0Fa4E8DE7b1B99FE524a7/ZPqrswR2QxFUPqP0Rng6Gl226NQDpG0nrYNFqx9-gfk?embedable=true Mark Helfman publishes the newsletter. He is also the author of three books and a top Bitcoin writer on and . Learn more about him in his and connect with him on or . Crypto is Easy Medium Hacker Noon bio Superpeer Tealfeed

The Crypto Market Demands You Suspend Your Disbelief

a SWOT analysis is an evaluation of the fundamental, operational, technical, social, economic, and even, to some degree, administrative elements of a project. This is not a model to be used for trading purposes. (NFA, DYOR) *Note: Composed of four elements, Strengths, Weaknesses, Opportunities, and Threats, a SWOT analysis framework provides excellent insight for establishing a high-level understanding of the state of a project's well-being through the lens of a birds-eye view. It can help formulate decisions around which areas require more attention, set performance goals, and organize a foundational understanding of where a project is headed. Rarely (if ever) used in crypto, it is time to apply this timeless method of evaluation to the digital asset space. Today, Stacks (STX), the layer 2 solution that is bringing smart contract capabilities to the Bitcoin network, will get a . SWOT 💪 Strengths (Internal) (Helpful) 1. PoX Consensus Model This is a very novel, creative solution for tithing the operational logic of the Stacks network to Bitcoin. Proof-of-transfer is a mechanism that utilizes transactional entropy as the underlying modality to mint new tokens. Credit must be given to Stacks for creating this system (which never existed prior), and it acts as a very abstract social pegging. Based on the use of assets from Proof-Of-Work-based chains, miners on the Bitcoin Network transfer their assets to Validators on Stacks (called Stackers) in return for the chance to stream the next batch of blocks and receive the newly minted STX tokens. 2. On-Chain TVL increasing The trendline of how much value is locked on Stacks in USD terms has been showing directionally improving. While it is possible that the trend benefits alongside a greater market recovery from the beginning of 2023, the fact there are already DEFI and NFT initiatives taking place on-chain signals a blue ocean of opportunity. 3. sBTC Attempting to bring TVL into its ecosystem in the form of Bitcoin and replicate the massive success of WBTC, sBTC promises to be the most trustless method of bridging BTC. Utilizing a two-way pegging system where users would deposit BTC into a nominated address that would then, in turn, be minted on Stacks at a 1:1 ratio and de-peg or move their assets back off of Stacks onto Bitcoin. What sets sBTC apart from all other pegging systems in the industry today is the architecture of capital flows. Bridging a BTC from Bitcoin to Stacks is permissionless and maximally frictionless; withdrawing requires some form of authority attestation. Stacks has devised a model for establishing the withdrawal authority in a maximally decentralized way. 4. Bridges to EVM chain Connecting the most prominent networks in terms of unlocks a new degree of capital, a new grade of developers, and a greater surface area for potentially marketing Stack's network in the smorgasbord of applications that live around the EVM ecosystem. At this time, Stacks is only bridged to Ethereum and Binance Smart Chain; however, introducing each new network should provide the project with some exciting technical roadmap developments over the next months/years. 5. Uses Bitcoin as Data Availability Layer In the new modular landscape where technologies are constantly introducing more complexity and more diversity in an attempt to cater to a still extremely young market, Stack’s focus on the Bitcoin ecosystem for data availability brings a novel level of decentralization and security to the dApp space. Data availability is arguably the most important part of any decentralized information system; given that Bitcoin is the most resilient (by raw computational power) and the most ridging, the data that Bitcoin's network governs can be thought of as being the most secure. This anchoring to Bitcoin allows STX to inherit some of its most desirable properties. 6. STX token was sold as an Approved Security Stacks token was the first to receive the regulatory green light to be sold to the public as a compliant digital asset. This makes STX an extremely interesting asset for potential Tradfi market participants. The sale took place in 2019, setting a precedent for any other projects in the space to follow in their footsteps. 7. STX Validator Incentives STX has one of the few, possibly only, models for the network participants (validators) to earn real yield through their involvement. Given that Stackers actually receive BTC that is used within its consensus model, there can be a real-world demand vector attributed to the STX token (even if only through second or third-degree relationships). 😞 Weaknesses (Internal) (Harmful) 1. BNS Abandoned Twice Stacks released BNS (Bitcoin Name Services) sometime in July of 2022. With over a year of observation, it seems that BNS does not really have that much of an important place in the digital asset market. Surely, it was released in the mother of all crypto bear markets, where approximately 300,000 BNS domains were sold. However, it has drawn a pattern of hype followed by absolute disregard. If the hype cooled down to a low of -95%, it would be feasible, but as the charts show us, the hype is followed by a fall to actual 0 in some cases. Moreover, all on-chain activity is to some degree faked by either project founders or supporters, or at the very least not Sybil conscious (a single entity can easily just own multiple BNS domains), likely arriving at a true number some odd 10x lower than the total amount sold. *This is by no means an existential crisis of any kind for Stacks, just some worthwhile food for thought in gauging ecosystemic resilience. 2. Bitcoin MEV Sharing a security model is known to be an obvious risk factor for MEV. Stacks was (and at this time still is) subject to the economic vulnerability present in the current version of PoX, where Bitcoin Miners can technically conduct fraudulent transactions without there being any risk to them; Stacks Network cannot punish Bitcoin Miners. Savvy miners came in and began only to include the actions related to their own nodes, pushing assets through a bottleneck that totally eliminated competition from other STX miners. 🧐 Opportunities (External) (Helpful) 1. Ultra Low Network DAU/DAA Both an opportunity and a threat. At the painfully modest level of roughly 3,000 Daily active users (not knowing how many of these are Sybils or bots), in the event the network gains a tiny portion of the interest that will flood the markets at some point, the potential external economic impact easily qualifies as enough to break previous ATH's. Moreover, considering how much quality infrastructure has actually been developed in the process, is STX attracts the developer community, then orders of magnitude growth await in terms of useability, adoption, and access. 2. No Real Competition Stacks has carved out a decently strong reputation for itself as THE project that is approaching Bitcoin programmability, scalability, and interoperability in the most crypto-pure way "decentralized." Positioned very uniquely against the few other participants (Liquid, Lighting Network, Rootstock), Stacks is the only one to provide the spectrum of benefits with minimal negative externalities. 3. Appealing to TradFi Stacks has carved out a niche that ticks the boxes for many traditional financial entities to be interested in participating in its ecosystem. The real yield of Bitcoin, the security of Bitcoin, a digital asset that was brought to market under regulatory supervision, scalable smart contract environment, and reputable findings with tremendous backing from prominent VCs. STX is easily crypto that likely every major enterprise will, at the very least, consider in their Web3 journies. 😳 Threats (External) (Harmful) 1. Graveyard of Bitcoin-based Solutions Rootstock, colored coins, Ordinals, and a handful of other attempts have been made to introduce more functionality on Bitcoin. Nearly all of them have failed to pick up steam, existing only within tiny niche communities until eventually dying off and becoming relics. If attempting to evaluate the long-term survivability of Stacks based on the niche it is operating in, the odds are stacked against them (pun intended). 2. Ultra Low Network DAU/DAA Both an opportunity and a threat. Ultra-low levels of adoption could be a direct indicator of the relative unimportance of the project or perhaps just a failure in marketing to users. Considering that at the absolute peak hype, the Stacks networks showed just about 9,000 daily active addresses. More likely than not, a decent portion of this can be attributed to bot activity, which dampens the interest levels even further. This extremely low level of engagement shows one of two things: either honesty from the network operators in showing activity or total disregard for the network, and the first inadvertently points to the second. Takeaway: Positive, unorthodox overall feeling about the project. Technology is there. Unique market position and produce offering is there. Marketing and social presence are definitely lagging, but out of all things, it is easiest to sort out. I'm not saying building communities is easy; I'm saying that building quality products is much more noble. Conclusion: Stacks is to Bitcoin what Polygon is to Ethereum. To be totally honest, I was an extreme skeptic of stacks. I actually considered it trash for a long while. But, after a thorough digging, I am humbled to admit that I was wrong; it's legit. While I now see the value proposition and understand why institutions might find this attractive, I would still NOT deposit my Bitcoin into sBTC and will most likely never use the smart contract network itself. Would I invest in the token itself (STX)? Yes. Small, controlled DCA with a better chance for higher returns than just holding Bitcoin. Under a different set of circumstances (where I had far more wealth), I would definitely explore becoming a validator on their network, but from my calculations, anything less than ~$500,000 is not worth the time. If you know something that I don't or feel as though I might have missed anything worth noting, please do share. I would tremendously appreciate some feedback. Thank you so much for reading, I hope this serves you well on your journey. Live long and prosper 🥂

The Stacks (STX) SWOT Analysis

Nowadays, an essential part of the development process is to track the performance of an application. Analyzing the processes in the system allows you to better understand which part of the project is working well, and where urgent fixes are needed. Among the many tools that allow you to monitor and debug, there is one that is very easy to customize in the Laravel framework, because it is made by the creators of the framework themselves. Its name is Telescope. Laravel Telescope is a debugging panel, with a user-friendly and modern design. Inside the panel you can find logs and statuses of all elements of the system. Features Laravel Telescope is a customized debugging panel with different aspects of the application, where each aspect is highlighted in a separate menu item. Telescope allows you to see all parts of the system, such as database accesses, cache accesses, how to work with built-in events, how to work with custom events. Also there is realized the display of requests to the system or errors. We will talk more about the features a little later, but for now let's set up the application. Local and production installation The main convenience of working with Telescope is that it can be configured literally in a couple of clicks. After installing the package you need to load the assets with the command telescope:install , and then run migrations. When installing only locally we need, after adding the package to dev dependencies and loading the assets, to remove the TelescopeServiceProvider connection from config/app.php, but set the provider connection depending on the environment in AppServiceProvider, for example as follows if ($this->app->environment('local')) {
   $this->app->register(\Laravel\Telescope\TelescopeServiceProvider::class);
   $this->app->register(TelescopeServiceProvider::class);
} After that you need to remove the Telescope package from discover in composer.json.
As for the production solution, there can't be one opinion. On the one hand - when installing and on production environment there is no need to finalize the connection, because in this case it will be available everywhere. It is also a plus, as it gives you the opportunity to quickly see what is happening with the state of production.
However, such a solution has a disadvantage and quite a big one.
Due to the fact that the data that is shown in Telescope is extremely sensitive, it is necessary to correctly configure the routing and disable it from being available without access to the corporate network.
In my opinion, the ideal connection would be to access a local Laravel Telescope that accesses all data sources within the corporate network.
The last step in setting up this tool is to set up the configuration in config/telescope.php Let's see how it works By default Telescope runs at /telescope. With a fresh installation, you probably won't see any requests or other data. But what we can say with certainty is that there is a lot of possibilities for this tool, if you look even just at the list of menus. As for the settings for connecting different services, we will talk about it below. In the meantime, it is still necessary to understand how to set up the panel for yourself. Prune command The first problem in our application is the problem with data deletion. Since Telescope collects all the data it sees, the database often quickly reaches its limit without deleting old records. Because of this, we need to update the database by force. Every application has a different frequency of data refresh, but if we're talking about a small project, we can do it on a daily basis. This can be achieved by running the artisan command telescope:prune, or by setting it automatically in Console\Kernel. Accessing the Telescope panel By default, working with the panel is only allowed locally. To fix this, you need to add some modified logic to the Gate check in TelescopeServiceProvider and specify there, for example, your email address. protected function gate(): void
{
   Gate::define('viewTelescope', function ($user) {
       return in_array($user->email, [
           'example@gmail.com'
       ]);
   });
} As you can see in the listing - adding a rule for validation is not a difficult task. Filters From time to time, when working with Telescope, especially in production, there is a problem with disk space. In order to avoid this and not to disable all logs so often, Laravel Telescope provides filters. They allow us to record only important parts, such as errors or dropped jobs. To change this we need to add or remove necessary/unnecessary parts in TelescopeServiceProvider, for example like this: Telescope::filter(function (IncomingEntry $entry) {
   if ($this->app->environment('local')) {
       return true;
   }


   return $entry->isReportableException() ||
          $entry->isFailedRequest() ||
          $entry->isFailedJob() ||
          $entry->hasMonitoredTag();
}); So the filters helped to limit the set of logs when working on production. Tags If you look at the previous listing, there is a method hasMonitoredTag(). It allows you to show all records that have a tag set, regardless of which watcher it belongs to. In order to set a tag on, for example, a query, you will need to add the following to the TelescopeServiceProvider: Telescope::tag(function (IncomingEntry $entry) {
   return $entry->type === 'request'
       ? ['status:'.$entry->content['response_status']]
       : [];
}); All tracked tags can be viewed by clicking on the button in the top right corner of the admin panel interface. Available watchers Finally, we have observed all the formalities and come to the most interesting part. Laravel Telescope contains a huge number of integrations with different services. Let's take a look at the most popular watchers. Adding a watcher to the system is done in the config/telescope configuration file. If you need to add login data to a new watcher, the new data is written directly to the 'watchers' key. The full list is quite large and while some work with obvious entities like CacheWatcher, CommandWatcher, RequestWatcher, others need a bit more detail. BatchWatcher - this watcher keeps track of sending jobs in batches. Read more about this method here EventWatcher and ModelWatcher - it's worth noting that EventWatcher does not track changes to models that use standard model events, unlike ModelWatcher GateWatcher - records all checks of gates and policies and their results. Below, for information, are examples of how some of the pages work. CacheWatcher Tracks cache hits, including unsuccessful ones. You can also see the passed arguments and options DumpWatcher Shows all calls to dump() function It is worth noting that this watcher does not work when using as a cache driver. array EventWatcher Shows all custom events that have occurred recently. You can also track the listener that worked on a particular event. ExceptionWatcher One of the most useful watchers, as it allows you to see errors, including the code where the error is thrown, as well as stacktrace Upgrade Telescope version It cannot be ignored that upgrading the Telescope version can cause some difficulties. To solve them, you need to follow all the steps of the guide on the official website, and make a couple of points. Due to the fact that the published assets may change during the upgrade, you need to upload them again during the upgrade, either manually or by setting post-update-cmd in composer.json Conclusion There are a huge number of all sorts of options on the market right now for debugging and tracking the state of a project. Laravel Telescope may not be very suitable for Production solutions, but for local development the tool is almost indispensable. It is worth noting that Laravel Telescope is updated quite often, which gives hope for long term support.

Companion for working with Laravel — Telescope

Hi all! My name is Taras Egorov; I'm an engineer at inDrive. I'll show you how we set up an infrastructure capable of running more than 5,000 tests per day on iOS and Android devices combined. The secret is simple: we used Selenoid. Preface Last year, our colleagues conducted a study of auto testing, and we took part in a survey as part of the study. We were pleased with the survey's findings, so we decided to write an article to share our experience with you and get some advice in return. We thought it a good idea to divide the material into two parts: the first one focusing on Android and the second on iOS. Let's begin with Android. Running the tests on Android Selenoid is a tool for running and managing browsers and Android emulators in a Docker container. You can read more about this . popular in the documentation To write Appium tests, we use: Kotlin; JUnit 5; Maven. The first run. Setting up Selenoid Create a config file: browsers.json {

  "android": {

    "default": "10.0",

    "versions": {

      "10.0": {

        "image": "browsers/android:10.0",

        "port": "4444",

        "path": "/wd/hub"

      }

    }

  }

} The emulator image is specified in . The guys from have prepared ready-made images of Android emulators. You can check them out or . The images don't differ from each other in any way. image aerokube here here Let’s take the image as an example. The image must be downloaded beforehand: , otherwise the tests will not run: browsers/android:10.0 docker pull browsers/android:10.0 Original error: create container: Error response from daemon: No such image: browsers/android:10.0 The next step is to run Selenoid. We do that directly via , or there’s the option of using . docker Configuration Manager docker run -d \

           -v /var/run/docker.sock:/var/run/docker.sock \

           -v "$(pwd)/selenoid/config/":/etc/selenoid/:ro \

           -p 4444:4444 \

           --name selenoid \

           aerokube/selenoid:1.10.7 You can check to see if Selenoid is working properly by following the link in your browser: http://localhost:4444 You are using Selenoid 1.10.7! Specify the Selenoid address in the Appium tests in the driver: ...
val driver = AndroidDriver(URL("http://localhost:4444/wd/hub"), capabilities)
... Next, specify the link to the build in capabilities: ... 
capabilities.setCapability("appium:app", "https://storage.example.com/builds/app.apk")
... If unable to provide a link, you can specify the path to the build:** ...
capabilities.setCapability("appium:app", "/builds/app.apk")
... Where is the path inside the container where the emulator is being run. For this option to work properly, be sure to specify the in : /builds/app.apk volumes browsers.json {

  "android": {

    "default": "10.0",

    "versions": {

      "10.0": {

        ...

        "volumes": [

          "/home/username/app.apk:/builds/app.apk:ro"

        ]

        ...

      }

    }

  }

} Where is the path to the build on the host platform. /home/username/app.apk That's it, we've almost set up Selenoid, and now we can try running the tests: ./mvnw test But, unfortunately, the tests will not be able to run. Let's look into this and see what's wrong. The second run. Taking a look at the logs and video The first thing to do after a failed startup is to check out the Selenoid logs: docker logs selenoid [INIT] [Loading configuration files...]
[INIT] [Loaded configuration from /etc/selenoid/browsers.json]
[INIT] [Video Dir: /opt/selenoid/video]
[INIT] [Your Docker API version is 1.41]
[INIT] [Timezone: UTC]
[INIT] [Listening on :4444]
[NEW_REQUEST] [unknown] [172.17.0.1]
[NEW_REQUEST_ACCEPTED] [unknown] [172.17.0.1]
[LOCATING_SERVICE] [android] [10.0]
[USING_DOCKER] [android] [10.0]
[CREATING_CONTAINER] [selenoid/android:10.0]
[STARTING_CONTAINER] [selenoid/android:10.0] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa]
[CONTAINER_STARTED] [selenoid/android:10.0] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa] [0.40s]
[0] [REMOVING_CONTAINER] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa]
[0] [CONTAINER_REMOVED] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa]
[0] [SERVICE_STARTUP_FAILED] [http://172.17.0.3:4444/wd/hub does not respond in 30s] We see that the status is SERVICE_STARTUP_FAILED. Go to the and look at the status value: documentation SERVICE_STARTUP_FAILED - Failed to start Docker container or driver binary The error doesn’t tell you much, and more information is required. It would be good to take a look at the container logs. Let's do that by enabling logging: docker run -d \

           -p 4444:4444 \

           -v /var/run/docker.sock:/var/run/docker.sock \

           -v "$(pwd)/selenoid/config/":/etc/selenoid/:ro \

           -v  "$(pwd)/selenoid/logs/":/opt/selenoid/logs/ \

           aerokube/selenoid:1.10.7 \

           -log-output-dir /opt/selenoid/logs We also enable logs in the Capabilities section: ...
capabilities.setCapability("enableLog", true)
... Run the tests and review the logs using the browser : http://localhost:4444/logs/ 2023-04-16T13:44:43.909768530Z Waiting X server...
2023-04-16T13:44:44.009494775Z Logging to: /tmp/fluxbox.log
2023-04-16T13:44:44.047587277Z Waiting X server...
2023-04-16T13:44:44.151933325Z Waiting X server...
2023-04-16T13:44:44.262850410Z * daemon not running; starting now at tcp:5037
2023-04-16T13:44:44.457972956Z * daemon started successfully
2023-04-16T13:44:44.458249266Z adb: no devices/emulators found
2023-04-16T13:44:45.463480812Z adb: no devices/emulators found
2023-04-16T13:44:46.471547723Z adb: no devices/emulators found
2023-04-16T13:44:47.476093515Z adb: no devices/emulators found
2023-04-16T13:44:48.481987351Z adb: no devices/emulators found
2023-04-16T13:44:49.486503149Z adb: no devices/emulators found
2023-04-16T13:44:50.492757801Z adb: no devices/emulators found
2023-04-16T13:44:51.499094108Z adb: no devices/emulators found
2023-04-16T13:44:52.505862428Z adb: no devices/emulators found
2023-04-16T13:44:53.513276412Z adb: no devices/emulators found
2023-04-16T13:44:54.520642210Z adb: no devices/emulators found
2023-04-16T13:44:55.527420189Z adb: no devices/emulators found
2023-04-16T13:44:56.534631013Z adb: no devices/emulators found
2023-04-16T13:44:57.316094939Z WARNING. Using fallback path for the emulator registration directory.
2023-04-16T13:44:57.335415397Z checkValid: hw configs not eq
2023-04-16T13:44:57.541959741Z adb: device offline
2023-04-16T13:44:58.547907700Z adb: device offline
2023-04-16T13:44:58.565504866Z emulator: WARNING: System image is writable
2023-04-16T13:44:58.565528396Z emulator: Cold boot: different AVD configuration
2023-04-16T13:44:58.565532576Z Your emulator is out of date, please update by launching Android Studio:
2023-04-16T13:44:58.565536346Z  - Start Android Studio
2023-04-16T13:44:58.565539506Z  - Select menu "Tools > Android > SDK Manager"
2023-04-16T13:44:58.565543076Z  - Click "SDK Tools" tab
2023-04-16T13:44:58.565546216Z  - Check "Android Emulator" checkbox
2023-04-16T13:44:58.565549216Z  - Click "OK"
2023-04-16T13:44:58.565552146Z 
2023-04-16T13:44:59.554451514Z adb: device offline
2023-04-16T13:45:00.560926060Z adb: device offline
2023-04-16T13:45:01.568777440Z adb: device offline
2023-04-16T13:45:12.124226047Z emulator: INFO: boot completed
2023-04-16T13:45:12.124251007Z emulator: INFO: boot time 27848 ms
2023-04-16T13:45:12.124255077Z emulator: Increasing screen off timeout, logcat buffer size to 2M.
2023-04-16T13:45:12.152557294Z emulator: Revoking microphone permissions for Google App. The container logs are not much help here either, because you can't see the Appium logs. Now let's try to enable them. To do this, let's look at the script : entry point.sh ...
if [ -z "$VERBOSE" ]; then
    APPIUM_ARGS="$APPIUM_ARGS --log-level error"
else
    EMULATOR_ARGS="$EMULATOR_ARGS -verbose"
fi
... To enable Appium logs, the parameters and : must be passed to the container: VERBOSE=true APPIUM_ARGS=--log-level debug {

  "android": {

    "default": "10.0",

    "versions": {

      "10.0": {

        ...

        "env": [

          "VERBOSE=true",

          "APPIUM_ARGS=--log-level debug"

        ]

        ...

      }

    }

  }

} To enable Appium to debug logs, you need to pass VERBOSE; in this case, the emulator logs turn on and start filling the "ether"” But we fixed that for future images =) Now it is enough to pass to . APPIUM_ARGS=-log-level debug ...
[HTTP] --> POST /wd/hub/session/c89fa9c2-ca2b-49cd-ab31-590eeccf77d1/element
[HTTP] {"using":"id","value":"authorization_edittext_phone"}
[debug] [W3C (c89fa9c2)] Calling AppiumDriver.findElement() with args: ["id","authorization_edittext_phone","
c89fa9c2-ca2b-49cd-ab31-590eeccf77d1"]
[debug] [BaseDriver] Valid locator strategies for this request: xpath, id, class name, accessibility id, -and
roid uiautomator
[debug] [BaseDriver] Waiting up to 0 ms for condition
[debug] [WD Proxy] Matched '/element' to command name 'findElement'
[debug] [WD Proxy] Proxying [POST /element] to [POST http://127.0.0.1:8200/wd/hub/session/65943f03-3b35-4d3eb221-d6dc7988f935/element] with body: {"strategy":"id","selector":
"authorization_edittext_phone","context":"","multiple":false}
[WD Proxy] Got response with status 404: {"sessionId":"65943f03-3b35-4d3e-b221-d6dc7988f935","value":{"error"
:"no such element","message":"An element could not be located on the page using the given search parameters","stacktrace":"io.appium.uiautomator2.common.exceptions.El
ementNotFoundException: An element could not be located on the page using the given search parameters\n\tat io.appium.uiautomator2.handler.FindElement.safeHandle(Find
Element.java:73)\n\tat io.appium.uiautomator2.handler.request.SafeRequestHandler.handle(SafeRequestHandler.java:41)\n\tat io.appium.uiautomator2.server.AppiumServlet.
handleRequest(AppiumServlet.java:253)\n\tat io.appium.uiautomator2.server.AppiumServlet.handleHttpRequest(AppiumServlet.java:247)\n\tat io.appium.uiautomator2.http.Se
rverHandler.channelRead(ServerHandler.java:68)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)\n\tat io
.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)\n\tat io.netty.chann...
[debug] [W3C] Matched W3C error code 'no such element' to NoSuchElementError
[debug] [W3C (c89fa9c2)] Encountered internal error running command: NoSuchElementError: An element could not
be located on the page using the given search parameters.
[debug] [W3C (c89fa9c2)]     at AndroidUiautomator2Driver.findElOrEls (/opt/node_modules/appium/node_modules/appium-android-driver/lib/commands/find.js:75:11)
[debug] [W3C (c89fa9c2)]     at process._tickCallback (internal/process/next_tick.js:68:7)
[HTTP] <-- POST /wd/hub/session/c89fa9c2-ca2b-49cd-ab31-590eeccf77d1/element 404 23 ms - 444
... As seen from the logs, Appium cannot find our element. Let's see what is happening on the emulator screen. To do this, we have to run the Selenoid UI: docker run -d \

           --name selenoid-ui \

           -p 8080:8080 \

           --link selenoid:selenoid \

           aerokube/selenoid-ui:1.10.4 \

           --selenoid-uri "http://selenoid:4444" Go to and open the Selenoid UI: http://0.0.0.0:8080 Be sure to enable VNC and video recording in the tests: ...

capabilities.setCapability("enableVNC", true)

capabilities.setCapability("enableVideo", true)

... The Selenoid startup command ends up looking like this: docker run -d \

-v /var/run/docker.sock:/var/run/docker.sock \

-v "(pwd)/selenoid/logs/":/opt/selenoid/logs/ \

-v /opt/selenoid/video/:/opt/selenoid/video/ \

-e OVERRIDE_VIDEO_OUTPUT_DIR="/opt/selenoid/video/" \

-p 4444:4444 \

-name selenoid \

aerokube/selenoid:1.10.7 \

-log-output-dir /opt/selenoid/logs Open the Selenoid UI once the tests are up and running: And here's . a video of it https://www.youtube.com/watch?v=Hm7s5ZjnVYQ&embedable=true We found the cause of the startup error. Great! Let’s move on. The third run. Building an emulator image As it turns out, the images of Selenoid emulators won’t work without Google Play services. To remedy this situation, you must build an emulator image yourself. The guys from aerokube have assembled everything you need for this: and . a repository with photos documentation the repository. Downloading Go to the folder. selenium Run the script and answer the questions. This is what it looks like in our case: ./automate_android.sh Specify Appium version: [1.18.1]

>> 1.18.1

Specify Android image type (possible values: "default", "google_apis", "google_apis_playstore", "android-tv", "android-wear"): [default]

>> google_apis

Specify Application Binary Interface (possible values: "armeabi-v7a", "arm64-v8a", "x86", "x86_64"): [x86]

>> x86

Specify Android version: [8.1]

>> 10.0

Specify device preset name if needed (e.g. "Nexus 4"):

>>

Specify SD card size, Mb: [500]

>>

Specify userdata.img size, Mb: [500]

>>

Are you building a Chrome Mobile image (for mobile web testing): [n]

>> y

Specify Chromedriver version if needed (required for Chrome Mobile):

>> 74.0.3729.6

Specify image tag: [selenoid/chrome-mobile:74.0]

>> android-emulator:10.0

Add Android quick boot snapshot? [y]

>> n When I saw the question Add Android quick boot snapshot?, I thought it was an emulator . But if you look at the , it calls a , which is needed to install APK applications. Basically, it doesn't give us any gain. snapshot code script We already use snapshot emulators , but we'll talk about that in other articles. to speed up container launches Once the image is built, we will be prompted to push it into the registry. Since we don't need that yet, we will kindly decline the offer: Push?  >> n We have put together a build with Google Play services. Remember to change the image parameter in browsers.json, and restart Selenoid. Now let's try rerunning the tests: [INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------ And of the test run. here’s a video https://www.youtube.com/watch?v=w-uzB7hg7g8&t=1s&embedable=true To sum up What we have done: Configured Selenoid to run Android tests. Learned how to check out the logs and videos to troubleshoot. Built our own emulator image with Google Play services. Something else I would like to tell you about: Selenoid timeouts. If your app is large, you might run into problems with timeouts. How we tried making the container run faster. The video shows that the run takes about a minute or so. How we tried running native Android tests written in Espresso on Selenoid. Spoiler alert: this works! Meanwhile, in the next part, we'll tell you how we scaled up the infrastructure and ran tests on iOS.

How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook (Part 1)

কিভাবে প্রতিদিন মোবাইল ডিভাইসে 5000+ পরীক্ষা চালাবেন; ইনড্রাইভের প্লেবুক থেকে (পর্ব 1)

So führen Sie täglich über 5000 Tests auf Mobilgeräten durch; Aus dem Playbook von inDrive (Teil 1)

Cómo ejecutar más de 5000 pruebas en dispositivos móviles todos los días; Del libro de jugadas de InDrive (Parte 1)

Comment exécuter plus de 5 000 tests sur des appareils mobiles au quotidien ; Du Playbook d'InDrive (Partie 1)

मोबाइल उपकरणों पर प्रतिदिन 5000+ परीक्षण कैसे करें; इनड्राइव की प्लेबुक से (भाग 1)

モバイルデバイスで毎日 5000 件以上のテストを実行する方法; InDrive のプレイブックより (パート 1)

매일 모바일 장치에서 5000개 이상의 테스트를 실행하는 방법 inDrive의 플레이북(1부)에서

Como executar mais de 5.000 testes em dispositivos móveis todos os dias; Do manual do InDrive (parte 1)

Her Gün Mobil Cihazlarda 5000'den Fazla Test Nasıl Çalıştırılır; inDrive'ın Başucu Kitabı'ndan (Bölüm 1)

Cách chạy hơn 5000 bài kiểm tra trên thiết bị di động mỗi ngày; Từ Playbook của InDrive (Phần 1)

如何每天在移动设备上运行 5000 多个测试；来自 InDrive 的剧本（第 1 部分）

I shall keep caddis worms

Debugging a Spring WebFlux application can be a challenging task, especially when dealing with complex reactive streams. Unlike traditional blocking applications, where the stack trace provides a clear indication of the root cause of an issue, reactive applications can be harder to debug. Issues such as blocking code, concurrency problems, and race conditions can all cause subtle bugs that are difficult to diagnose. Scenario When dealing with a bug it’s not always a code-related issue. It could be a set of factors, such as recent refactoring, team changes, hard deadlines and so on. In real life, it’s a common thing to end up troubleshooting large applications made by people who left the company a while back, and you just joined. Knowing a little about a domain and technologies isn't going to make your life easier. In the code example below, I wanted to imagine how a buggy code could look like for a person recently joined a team. Consider debugging this code more like a journey rather than challenge. The root cause could be obvious to find for those who are familiar with Reactive apps. However, some practices down below could be still very helpful to revise. @GetMapping("/greeting/{firstName}/{lastName}")
public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) {

    return Flux.fromIterable(Arrays.asList(firstName, lastName))
            .filter(this::wasWorkingNiceBeforeRefactoring)
            .transform(this::senselessTransformation)
            .collect(Collectors.joining())
            .map(names -> "Hello, " + names);
}

private boolean wasWorkingNiceBeforeRefactoring(String aName) {
    // We don't want to greet with John, sorry
    return !aName.equals("John");
}

private Flux<String> senselessTransformation(Flux<String> flux) {
    return flux
            .single()
            .flux()
            .subscribeOn(Schedulers.parallel());
} So, what this piece of code does is: It prepends “Hello, “ to the names provided as parameters. Your colleague John is telling you that everything works on his laptop. That’s true: > curl localhost:8080/greeting/John/Doe 
> Hello, Doe But when you run it like , you see the next stacktrace: curl localhost:8080/greeting/Mick/Jagger java.lang.IndexOutOfBoundsException: Source emitted more than one item
	at reactor.core.publisher.MonoSingle$SingleSubscriber.onNext(MonoSingle.java:134) ~[reactor-core-3.5.5.jar:3.5.5]
	Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
Error has been observed at the following site(s):
	*__checkpoint ⇢ Handler com.example.demo.controller.GreetingController#greeting(String, String) [DispatcherHandler]
	*__checkpoint ⇢ HTTP GET "/greeting/Mick/Jagger" [ExceptionHandlingWebHandler]
Original Stack Trace: <18 internal lines>
		at java.base/java.util.concurrent.FutureTask.run(FutureTask.java) ~[na:na] (4 internal lines) Nice, neither of the traces leads to a code sample above. All it reveals is that 1) it occurred in the method, and 2) the client performed an `HTTP GET "/greeting/Mick/Jagger GreetingController#greeting .doOnError() First and the easiest thing to try out is to add `.doOnError()` callback to the end of the greeting chain. @GetMapping("/greeting/{firstName}/{lastName}")
public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) {

    return Flux.fromIterable(Arrays.asList(firstName, lastName))
            // <...>
            .doOnError(e -> logger.error("Error while greeting", e));
} Nice try, but logs don't show any improvement. Nonetheless, Reactor's internal stack trace: Here are some ways can/can’t be helpful during debugging: doOnError : You can use to log error messages and provide more context about what went wrong in your reactive stream. This can be especially helpful when debugging issues in a complex stream with many operators. Logging doOnError : can also be used to recover from errors and continue processing the stream. For example, you can use to provide a fallback value or stream in case of an error. Recovery doOnError onErrorResume : most probably won’t provide any better stacktrace except what you already saw in the logs. Don’t rely on it as a good troubleshooter. Debugging doOnError log() Next stop is to replace previously added by method call. As simple as it gets. observes all Reactive Streams signals and traces them into logs under INFO level by default. doOnError() log() log() Let’s see what additional info we see in logs now: We can see what Reactive methods have been called ( , and ). Additionally, knowing which threads (pools) these methods have been called from can be very useful information. However, it is not relevant to our case. onSubscribe request onError About thread pools Thread name stands for . Reactive methods and were executed on IO thread pool (scheduler). These tasks were executed immediately on a thread that submitted them. ctor-http-nio-2 reactor-http-nio-2 onSubscribe() request() By having inside we’ve instructed Reactor to subscribe further elements on another thread pool. That’s the reason why has been executed on thread. .subscribeOn(Schedulers.parallel()) senselessTransformation onError parallel-1 You can read more about thread pool . in this article method allows you to add logging statements to your stream, making it easier to track the flow of data and diagnose issues. If we were having more complex data flow with things like flatMap, subchains, blocking calls, etc., we would benefit much from having it all logged down. It’s a very easy and nice thing for daily use. However, we still don’t know the root cause. log() Hooks.onOperatorDebug() Instruction tells Reactor to enable debug mode for all operators in reactive streams, allowing for more detailed error messages and stack traces. Hooks.onOperatorDebug() According to the official documentation: When errors are observed later on, they will be enriched with a Suppressed Exception detailing the original assembly line stack. Must be called before producers (e.g. Flux.map, Mono.fromCallable) are actually called to intercept the right stack information. The instruction should be called once per runtime. One of the best places would be Configuration or Main classes. For our use case it would be: public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) {

    Hooks.onOperatorDebug();

    return // <...>
} By adding we can finally make progress in our investigation. Stacktrace is way more useful: Hooks.onOperatorDebug() And on line 42 we have call. single() Don’t scroll up, the looks next: senselessTransformation private Flux<String> senselessTransformation(Flux<String> flux) {
    return flux
            .single()  // line 42
            .flux()
            .subscribeOn(Schedulers.parallel());
} That’s the root cause. emits one item from Flux source or signals for a source with more than one element. That means flux in the method emits more than 1 item. By going up in the call hierarchy we see that originally there is a Flux with two elements . single() IndexOutOfBoundsException Flux.fromIterable(Arrays.asList(firstName, lastName)) Filtering method removes an item from a flux when it equals to . That’s the reason why the code works for a college named John. Huh. wasWorkingNiceBeforeRefactoring John can be particularly useful when debugging complex reactive streams, as it provides more detailed information about how the stream is being processed. However, enabling debug mode can impact the performance of your application (due to the populated stack traces), so it should only be used during development and debugging, and not in production. Hooks.onOperatorDebug() Checkpoints To achieve nearly the same effect as gives with minimum performance impact, there is a special operator. It will enable debug mode for that section of the stream, while leaving the rest of the stream unaffected. Hooks.onOperatorDebug() checkpoint() Let’s add two checkpoints after filtering and after transformation: public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) {

    return Flux.fromIterable(Arrays.asList(firstName, lastName))
            .filter(this::wasWorkingNiceBeforeRefactoring)
 /* new */  .checkpoint("After filtering")        
            .transform(this::senselessTransformation)
 /* new */  .checkpoint("After transformation")
            .collect(Collectors.joining())
            .map(names -> "Hello, " + names);
} Take a look at the logs: This checkpoints breakdown tells us that the error has been observed after our second checkpoint described as . It doesn’t mean that the first checkpoint hasn’t been reached during execution. It was, but the error started to appear only after the second one. That’s why we don’t see . After transformation After filtering You can also see two more checkpoints mentioned in the breakdown, from and . They were reached after the one we set, down to the call hierarchy. DispatcherHandler ExceptionHandlingWebHandler Besides description, you can force Reactor to generate a stacktrace for your checkpoint by adding as the second parameter to method. It’s important to note that the generated stacktrace will lead you to the line with a checkpoint. It won’t populate a stacktrace for the original exception. So it doesn’t make a lot of sense because you can easily find a checkpoint by providing a description. true checkpoint() Conclusion By following these best practices, you can simplify the debugging process and quickly identify and resolve issues in your Spring WebFlux application. Whether you're a seasoned developer or just starting out with reactive programming, these tips will help you improve the quality and reliability of your code, and deliver better experiences for your users.

How to Debug a Spring WebFlux Application

Cómo depurar una aplicación Spring WebFlux

Comment déboguer une application Spring WebFlux

स्प्रिंग वेबफ्लक्स एप्लिकेशन को कैसे डिबग करें

Spring WebFlux アプリケーションをデバッグする方法

Como depurar um aplicativo Spring WebFlux

Cách gỡ lỗi ứng dụng Spring WebFlux

如何调试 Spring WebFlux 应用程序

Building Your Own Programming Language From Scratch: Part X - Exceptions Handling

I have always wondered what set of code to run in the background to make my app powerful and responsive, but I don’t really know how. Some time ago, I got to know about isolates and tried implementing them. And I should tell you, it was painful. But I recently discovered how easy it has become. So here it is. You might have heard about isolates but never really understood them. Or maybe you might have implemented isolates, but the code was always messy and tedious to write. In any case, this blog will guide you through the ups and downs of the Isolate history and the current and better implementation that you should follow. You might want to use the latest method, or you might want to use the old method after all, it’s all up to you. The basics This is how the defines Isolates Flutter Documentation An isolated Dart execution context. Did you understand anything? At least I did not. So let’s begin understanding Isolates and then we’ll write our own definition. So what do we need for Isolates Recipe? What are Isolates? Why do we need them? What is Event Handling? How to implement Isolates? And finally, what are Isolate Groups? We’ll start with the bigger picture of Isolates and see what it really means and go deep down and piece all the parts together to see how each part of it works together so that we can understand what Isolates really do and why we need them. What are Isolates? To really understand isolates, first we need to go further back and make sure we know the answer to these two questions: What is the difference between Processor Cores and Threads? Core is a physical hardware component whereas thread is the virtual component that manages the tasks of the core. Cores enable completion of more work at a time, while threads enhance computational speed and throughput. Cores use content switching but threads use multiple processors for executing different processes. What is the difference between concurrent and parallel processing? Concurrency is when two or more tasks can start, run, and complete in overlapping time periods. It doesn’t necessarily mean they’ll ever both be running at the same instant. For example, multitasking on a single-core machine. Parallelism is when tasks literally run at the same time, e.g., on a multicore processor. Let’s get back to Isolates. Dart uses the Isolate model for concurrency. Isolate is nothing but a wrapper around the thread. But threads, by definition, can share memory which might be easy for the developer but makes code prone to race conditions and locks. Isolates, on the other hand, cannot share memory and instead rely on message-passing mechanisms to talk with each other. If anything is difficult to comprehend, keep reading. I am sure, you’ll get it. Using isolates, Dart code can perform multiple independent tasks at once, using additional cores if they’re available. Each Isolate has its own memory and a single thread running an event loop. We’ll get to the event loop in a minute. Why do we need Isolates? Before we get into more detail, we first need to understand how async-await really works. void main() async {
  // Read some data.
  final fileData = await _readFileAsync();
  final jsonData = jsonDecode(fileData);

  // Use that data.
  print('Number of JSON keys: ${jsonData.length}');
}

Future<String> _readFileAsync() async {
  final file = File(filename);
  final contents = await file.readAsString();
  return contents.trim();
} We want to read some data from a file, decode that JSON, and print the JSON Keys length. We don’t need to go into the implementation details here but can take the help of the image below to understand how it works. When we click on this button , it sends a request to _readFileAsync, all of which is dart code that we wrote. But this function _readFileAsync, executes code using Dart Virtual Machine/OS to perform the I/O operation which in itself is a different thread, the I/O thread. This means, the code in the main function runs inside the main isolate. When the code reaches the _readFileAsync, it transfers the code execution to I/O thread and the Main Isolate waits until the code is completely executed or an error occurs. This is what await keyword does. Place Bid Now, once the contents of the files are read, the control returns back to the main isolate and we start parsing the String data as JSON and print the number of keys. This is pretty straight forward. But let’s suppose, the JSON parsing was a very big operation, considering a very huge JSON and we start manipulating the data to conform to our needs. Then this work is happening on the Main Isolate. At this point of time, the UI could hang, making our users fustrated. What is Event Handling? As we discussed, Isolate is a wrapper around thread and each Isolate has an event loop executing events. These events are nothing but what happens when we use the application. These events are added in a queue which then the Event loop takes in and processes. These events are processed in the first-in-first-out fashion. The image below is just an example. Let’s use this code again for understanding event handlers. We already know what is happening in this block. void main() async {
  // Read some data.
  final fileData = await _readFileAsync();
  final jsonData = jsonDecode(fileData);

  // Use that data.
  print('Number of JSON keys: ${jsonData.length}');
}

Future<String> _readFileAsync() async {
  final file = File(filename);
  final contents = await file.readAsString();
  return contents.trim();
} Our apps start and it draws the UI (Paint Event) is pushed on to the queue. We click on the button and and file handling code starts. So the Tap Event is pushed in the queue. After it is complete, let’s suppose the UI is updated, so again the Paint Event is pushed in the queue. Place Bid Now because the our logic for handling the file and JSON was very small, the UI doesn’t stutter or jank. But let’s, for a while, imagine again that out code for handling file was huge and it takes a lot of time. Now the event queue and the event loop looks similar to this image below. Now that the main isolate takes a lot of time to actually process that event, our animation or UI might hang and irritate your users, causing huge dropoffs. This is where spawning a new isolate or a worker Isolate comes in. How to implement Isolates? All our dart code in the flutter app runs in isolate. Whether it is a main isolate or a worker isolate is up to you. The main isolate is created for you and you don’t have to do anything else here. The main function starts on the Main Isolate. Once we have our main function running, we can start spawning new isolates. So there’s 2 ways of implementing Isolates, the short and new method or the long and old method. We can use either, depending on the use case. Let’s start with the already existing method. As we had already discussed, Isolates, unlike threads, don’t share memory. This is done so as to prevent race conditions and locks. But the communication between Isolates is done using message passing. These messages are primitives and you can check out the whole list of objects that can be passed between isolates . here To pass messages, Dart provides us with Ports. SendPort and ReceivePort. Since we’re discussing the old method for spawning Isolates, we need to know that isolate methods need to be top-level or static functions. Here is the to the code if you want to follow along. link Future<String> startDownloadUsingOldIsolateMethod() async {
  const String imageDownloadLink = 'this is a link';
  // create the port to receive data from
  final resultPort = ReceivePort();
  // spawn a new isolate and pass down a function that will be used in a new isolate
  // and pass down the result port that will send back the result.
  // you can send any number of arguments.
  await Isolate.spawn(
    _readAndParseJson,
    [resultPort.sendPort, imageDownloadLink],
  );
  return await (resultPort.first) as String;
} What does this code do: Here we create an instance of RecievePort to receive data. Remember this is the old method for spawning Isolates. It can be a little long but it is necessary to know the details. We create a Worker Isolate on the Main Isolate using Isolate.spawn and pass down a top-level function that runs the blocking code. We also pass down a list of arguments, the first one, SendPort which will be used to send the data from the worker Isolate, and the second is the download link. We wait till the new Isolate has been spawned. We then wait for the result, which is some form of a String and use it however we want. This data can be anything from list of object. this ResultPort.first uses a stream subscription behind the screen and waits for the data from the worker isolate to be pushed onto it. As soon as the first item arrives, we return the result. This is the _readAndParseJson function that receives the argument and runs the worker isolate code. This is a dummy function that does nothing but delays the control for 2 seconds and then exits. The exit function terminates the current isolate synchronously. Certain checks are performed before sending the data back to the calling isolate and the data is sent back using the SendPort. // we create a top-level function that specifically uses the args
// which contain the send port. This send port will actually be used to
// communicate the result back to the main isolate

// This function should have been isolate-agnostic
Future<void> _readAndParseJson(List<dynamic> args) async {
  SendPort resultPort = args[0];
  String fileLink = args[1];

  String newImageData = fileLink;

  await Future.delayed(const Duration(seconds: 2));

  Isolate.exit(resultPort, newImageData);
} Although this functions correctly but we have not handled any errors which can be thrown from the worker isolate or any error which can occur while spawning a new isolate. // Error Handling
Future<String> startDownloadUsingOldIsolateMethodWithErrorHandling() async {
  const String imageDownloadLink = 'this is a link';
  // create the port to receive data from
  final resultPort = ReceivePort();
  // Adding errorsAreFatal makes sure that the main isolates receives a message
  // that something has gone wrong
  try {
    await Isolate.spawn(
      _readAndParseJson,
      [resultPort.sendPort, imageDownloadLink],
      errorsAreFatal: true,
      onExit: resultPort.sendPort,
      onError: resultPort.sendPort,
    );
  } on Object {
    // check if sending the entrypoint to the new isolate failed.
    // If it did, the result port won’t get any message, and needs to be closed
    resultPort.close();
  }

  final response = await resultPort.first;

  if (response == null) {
    // this means the isolate exited without sending any results
    // TODO throw error
    return 'No message';
  } else if (response is List) {
    // if the response is a list, this means an uncaught error occurred
    final errorAsString = response[0];
    final stackTraceAsString = response[1];
    // TODO throw error
    return 'Uncaught Error';
  } else {
    return response as String;
  }
} Everything is pretty same here, we just have added error handling here. What this code does is: We add errorsAreFatal to true while spawning a new isolate to make sure that the Main Isolate is aware of any errors. We assign the SendPort for onExit and onError handlers to make sure that if any errors that occur during exiting or spawning. We also add a try-catch block while spawning a new isolate to make sure that if any error occurs during spawning, we catch that and stop this operation, altogether. If the spawning is successful and some data do come from the worker isolate, we need to check if it’s error or not. If the message sent back is null, this means the isolate exited without any message, and an error has occurred. If the response is a list, this means the worker Isolate has sent back an error and a stacktrace. Else this is a successful transaction. This does seem like an overkill if we wanted to do just one-off message passing. One message and close the Isolate. Everytime you wanted to spawn a new isolate you’ll have to write the same code again. Since the Isolate logic is pretty custom. Every time you might want to pass in some different arguments and it would be very tedious. This is why a new method was devised for one-off transactions. The new method: Isolate.run // Isolates with run function
Future<String> startDownloadUsingRunMethod() async {
  final imageData = await Isolate.run(_readAndParseJsonWithoutIsolateLogic);
  return imageData;
}

Future<String> _readAndParseJsonWithoutIsolateLogic() async {
  await Future.delayed(const Duration(seconds: 2));
  return 'this is downloaded data';
} This is all there is for the new method. We spawn a new Isolate using the run method which abstracts out all the granular details and the error handling and saving you a lot of time. This helps in spawning, error handling, message passing and terminating the Isolate all using these few little lines of code. One thing to note here is that the function _readAndParseJsonWithoutIsolateLogic, does not contain any custom logic for the Isolate. No ports, no arguments. When to use the new Run method and when to use the old spawn method? These examples above shows message passing that happens only 1 time. So run method should be used. It greatly reduces the code lines and test cases. But if you want to create something that needs multiple messages to be passed between the Isolates, we need to use the old method. An example of this could be when you start downloading a file on a worker isolate and want to show the progress of the download on the UI. This means the progress count needs to be passed again and again. Isolate.spawn() With this, we need to implement the whole SendPort and ReceivePort for message passing and the custom logic for receiving the arguments and sending the progress back to the main Isolate. What are Isolate Groups? So, we already know how Isolates passes messages to each other. But let’s assume, the message we are passing is a huge JSON. Before Dart 2.15, this huge object passing, could involve stutter in UI. This is because, we already know that Isolate has some memory, and when one Isolate passes an object to the other, that object had to be deep copied. This meant, a lot of time for copying the object to the main Isolate which can cause a jank. To avoid this circumstance, Isolates were reworked and Isolate Groups were invented. Isolate Groups, meaning a group of isolates, which share some common internal data structures representing the running application. This means each time a new Isolate is spawned, new internal data structures don’t need to be constructed again. Because they share them together. Don’t confuse these internal data structures with the mutable objects. The Isolates still can’t share this memory with each other. Message passing is still needed. But, because Isolates in the same Isolate group, share the same heap, this means spawning a new Isolate is 100 times faster and consume 10–100 times less memory. An example is a worker isolate that makes a network call to get data, parses that data into a large JSON object graph, and then returns that JSON graph to the main isolate. Before Dart 2.15, that result needed to be deep-copied, which could itself cause UI jank if the copy took longer than the frame budget. This means that the main Isolate can receive this JSON in almost constant time. And sending messages is now approximately 8 times faster. The good news is that, if you’re using Flutter version greater than 2.8, you don’t need to do anything to use these advancements. Hope you liked the understanding of Isolates. If you have any doubts, please comment. Reference for this code: https://github.com/DhruvamSharma/NFT-Material3?embedable=true Also published . here

Running Parallel Code in Flutter With Isolates

Nowadays every modern web application uses platforms that provide error monitoring in real-time. They have support for different languages and technologies. And that’s great because the quality of development grows every year. I’m a big fan of tools that help my team instantly react to bugs and crashes and fix them ASAP. It’s necessary when you are building a startup and trying to show your customers the best service. For instance, we used to monitor our frontend errors in and fixed repeated crashes for the mobile Safari browser. That was a big win because I had started to hate that issue (everyone faced that issue which cost him plenty of hours to find the solution). Recently, my team made the decision to migrate our front-end projects from Airbrake to . And like a big part of other developers, I was struggling with uploading source maps there. Airbrake Sentry I think the following solutions can help those who have and versions on their projects. ~Next.js@12 ~@sentry/nextjs@7.3+ Solution 1 If you see a notification similar to that in the picture below on an Issue page inside Sentry don’t fret. skipped the uploading of some source maps for Next.js generated files. In my case, those were errors that related to the framework/main files. @sentry/nextjs A little explanation: When Sentry is reacting to any error or event, it tries to get the source maps from the archive that it has uploaded. According to the GitHub issue conversation, the framework's code does not get uploaded by default anymore and Sentry doesn’t have access to all files for resolving stack trace. release Take a look at this note from Sentry manual setup documentation: If you find that there are in-app frames in your client-side stack traces that aren't getting source-mapped even when most others are, it's likely because they are from files in rather than . By default, such files aren't uploaded because the majority of the files in only contain Next.js or third-party code, and are named in such a way that it's hard to distinguish between relevant files (ones containing your code) and irrelevant ones. static/chunks/ static/chunks/pages/ static/chunks/ To make it upload everything, try to expand your current with the next properties. next.config.js // next.config.js
module.exports = withSentryConfig(
  {
	...yourNextConfig,
	sentry: {
	   widenClientFileUpload: true,
	}
  },
  {
	...yourWebpackSentryConfig,
	ignore: [],
  },
  yourSentryConfig,
); It helped me to resolve 2 of the 3 errors that I got. For the majority, it’ll solve 100% of problems with source maps. Solution 2 Let’s move on. The last problem was related to a square brackets notation for dynamic route values. If I catch an error on the client side(browser side), the stack trace paths are sent encoded but they’re not decoded when they reach the sentry server. Since the path is encoded and the string is not equal to , the source map is not matched/not found/whatever. When Sentry is sending the frames, it includes this encoded URL instead of the decoded URL. %5Bslug%5D.js [slug].js I’ve found the solution in rewriting StackFrame. Just follow the next instructions: Install package to expand your current client config. @sentry/integrations npm install --save @sentry/integrations I your add the next instruction sentry.client.config.js import { RewriteFrames } from '@sentry/integrations';

Sentry.init({
  ...yourSentryClientConfig,
  integrations: [
    ...yourSentryClientConfig.integrations,
    new RewriteFrames({
      iteratee: frame => {
        frame.filename = frame.filename.replace(distDir, 'app:///_next');
        // here we are decoding our square brackets []
        frame.filename = decodeURI(frame.filename);
        return frame;
      },
    }),
  ],
}); Great! I hope this solves at least one person’s problems! As new technologies constantly evolve, their versions get mismatched and make many developers cry. But god bless a huge programmer community that is glad to share their experience with others.

How to Upload Source Maps to Sentry with Next.js

Many people confuse monitoring and observability. While the words have similar definitions, they have significantly different meanings in a DevOps context. It's critical to understand these differences to select the best quality assurance and bug tracking solutions for your project – and ultimately minimize the number of bugs reaching production. Let's look at the similarities and differences between monitoring and observability and how you can pair the two strategies to minimize the number and severity of bugs reaching production. Monitoring and observability may have similar definitions, but they're completely different concepts in a DevOps context. Defining Monitoring & Observability systems watch a predefined set of metrics and logs to detect known failure modes. For example, you might look at response time metrics to spot potential scalability problems. If response times increase, you might spin up new servers to ease the load. You can also look at long-term trends to predict future performance issues. Monitoring systems help you understand a system's internal status from its external outputs. While observable systems have monitoring in place, they go a step further and track down the root cause of problems within the application stack. In other words, it helps move beyond what happened and when to understand why it happened and how to fix it. Observability Observability also identifies problems that aren't known. For example, monitoring systems may identify increased response times, but observability might pin a database query as the root cause. As a result, you may be able to implement a simple query change rather than paying for new server capacity. The "Three Pillars" of Observability Observability consists of three "pillars" – logs, metrics, and traces. While monitoring metrics, identify problems, logs and traces help diagnose the root cause of these problems by analyzing both the network and the application. As a result, observable systems must include all three pillars to effectively diagnose and resolve bugs. The three pillars include: Logs receive timestamps and are immutable records of discrete events that provide insight into what happened when things went wrong. You can easily parse logs using visualizations or quickly query them to find information with structured logs. Logs: Metrics are counts or measurements that you can aggregate over time. For example, metrics might track memory usage levels or request throughput, establishing baselines and making it easier to see abnormal behavior. Metrics: Traces provide a detailed overview of a single request to determine what components caused errors. By monitoring a request throughout an application stack, you can quickly diagnose what's causing a problem or identify performance bottlenecks. Traces: Observability + Monitoring Monitoring and observability are not mutually exclusive concepts. Rather, every observable system has monitoring capabilities built-in by definition. Monitoring tells you when something is wrong, and observability helps you understand why. But unfortunately, building observable systems can quickly become a challenge with complex systems. Some best practices include: Start by identifying the key metrics that apply to your application, such as CPU usage, storage capacity, or transactions per second. Then, set up tracking systems to monitor these metrics and trends over time. Identify Key Metrics: Implement structured logs that are easy to parse using languages like YAML or JSON. Then, identify solutions like OpenTelemetry that can help you quickly visualize and query logs to find the information you need. Structure Your Logs: Seek out tracing solutions that work with your application stack to quickly track down the root cause of issues. The best solutions can even help automatically create bug reports and communicate them with the rest of your team. Effectively Trace: Continuous integration and development (CI/CD) make it easy to automate observability. For instance, you might configure minimum error thresholds for new releases and hold back those with sub-par stability scores. Automate Processes: The Bugsnag Approach Bugsnag is a robust full-stack observability solution. Unlike conventional monitoring solutions, such as APM tools, the platform provides rich end-to-end diagnostics to help reproduce every error. In addition, help you prioritize bugs, balance bug-squashing with new feature development, and streamline team communication. Bugsnag's unique tools Bugsnag’s makes it easy to identify errors occurring when a feature flag or experiment was active. Source: Bugsnag Features Dashboard There are a few steps to the process: Set stability targets that measure the percentage of user sessions in a crash-free release. Doing this allows you to quickly determine if a new release meets minimum stability requirements or if it needs holding back to troubleshoot. Stabilize: Prioritize bugs based on their severity by looking at the number of users impacted. In addition, you can use bookmarks to identify errors impacting VIP customers or affecting SLAs. That way, you can focus only on what matters most. Prioritize: Stacktraces make it easy to pinpoint the exact line of code causing issues while retracing user actions that may have led to the error. In addition, you can automatically notify relevant teams based on bookmarks, preventing notification fatigue. Fix: The Bottom Line Monitoring and observability are critical DevOps concepts, but often they are misunderstood. While monitoring tracks any errors that occur, observability helps identify the root cause of the error to assist in fixing the problems. For example, they can use traces to identify application code responsible for network-level slowdowns. That said, production applications fail for all kinds of reasons, and there will always be something that goes wrong. The key to success is understanding what’s going wrong and determining what’s worth fixing rather than simply hoping nothing bad happens. Using all-in-one tools like Bugsnag, you streamline bug tracking and remediation using monitoring and observability tools. It's the easiest way to spot problems, troubleshoot bugs, and focus on the most impactful activities to build long-term value for your users. At the same time, the platform makes it easy to route problems to the right developers at the right time to fix. or today! Sign up for a free trial request a demo

So, How are Observability and Monitoring Different, Actually?

This blog is derived from the App Stability Series webinar, “Unlocking Bugsnag's Power Features,” a series focused on showcasing Bugsnag’s most powerful features that deliver an effective app stability experience. As digital transformation accelerates across verticals and consumers continue to adopt more applications into daily life, the engineering organizations behind these applications need to scale their teams, infrastructure and processes accordingly. Demand for new and improved functionality pushes for shorter development cycles and drives the adoption of progressive delivery practices. Traffic and data volumes continuously increase and apps integrate with more third-party services, increasing interdependency. All of this puts a strain on the ability to efficiently monitor app health and stability, as well as identify root causes of bugs. There is quite a bit of flexibility within Bugsnag that can sometimes go unnoticed by our users. Although Bugsnag's main functionality can be stood up in a matter of minutes by adding our SDK to your application, we do have a lot of features to address problems at scale and have collected some smart solutions from working with our power users. Some of these best practices are laid out below for your teams to leverage. Not All Bugs are Created Equal Some bugs prevent users from being able to complete critical functions or revenue-generating activity. Some crashes can quickly be isolated from users if they are known to be specific to a release version or a feature toggle. Other functional problems, like ANRs, app hangs and out of memory exceptions (OOMs) could be coming from outside of your code itself. Some of the visibility and monitoring challenges we often hear from engineering teams, of every size and across all verticals, are: : Taking the live stream of exceptions and honing in on specific situations, like crashes in specific critical paths & user bases, crashes related to live ops issues like third party outages, or A/B tests going wrong. Isolating incidents : Utilizing engineering resources to manually triage incoming errors or investigate issues that turn out not to be priorities. This includes errors coming from low-end devices, bot traffic and browser extensions. Sifting through noise : Additional complexity is introduced when features are shipped more frequently. Further manual work is introduced in trying to correlate errors and find causation across many app versions and active experiments or feature flags. Correlating errors with specific releases or feature toggles How Bugsnag can be Configured to Protect Revenue and Reduce Noise In order to provide a richer context for your errors, custom metadata may be added. This is incredibly helpful in tracking additional business or industry specific attributes and allowing for this information to be searched against within your errors. Custom metadata opens a range of possibilities, especially since bookmarks allow you to save searches in your team’s inbox, track trends and automate alerting or ticket creation to specific error segments. Some relevant metadata concepts Bugsnag users leverage today are listed below. Key Metadata Concepts: : From eCommerce apps with loyalty or membership programs to gaming apps where users accumulate a lifetime spend, logging the customer's loyalty status to your app is a crucial way to segment and track the experiences of your most important user bases. Customer Tier/ Type We recommend segmenting out errors in production where the user is of high value – this way custom notifications can be leveraged to notify your customer success organization if there are spikes in errors in this segment. This gives the team the ability to proactively respond to any highly valued users who run into significant issues with your application. : Understanding if an ANR, app hang or OOM error is coming from a performance issue in the application or from the user's device can be a very valuable distinction to reduce noise and properly prioritize. Some Bugsnag users maintain an internal mapping of device manufacturer or name to a classification (i.e., low, medium, high), and add this as metadata. Device tier If you monitor ANRs, OOMs or app hangs in your app, we recommend implementing a similar mapping and adding device tier metadata, so that all bookmarks tracking these errors can specifically exclude any exceptions coming from low-end devices. : By default, Bugsnag provides metadata in Android, iOS, React Native, Unity and Unreal that identifies if the app was launching during the time of the exception. The point at which your app is considered “launched” is configurable and can be either time-based or declared manually (see the "Identifying Crashes at Launch" section of our documentation). isLaunching We recommend creating a “Launch Crashes” bookmark where the parameter isLaunching = true, as this will allow you to track trends in launch crashes. I also recommend taking a look at a led by Ivan Diaz, which includes a live demo on detecting and remediating crash loops from within your app code. webinar : Network request information can be an important indicator when monitoring errors. Information like the last requested service, last request status and last response duration are powerful metadata to track. This can provide insights for gaming applications connecting with ad networks, or for general live ops issues, such as detecting spikes in errors potentially caused by payment or other third-party service outages. Third Party Requests In iOS/Android applications, we recommend leveraging a callback function to check the event’s breadcrumb data for any network requests, and attaching the most recent network request details as custom metadata. Network breadcrumbs must be enabled in order to implement this approach. With this metadata added, it's possible to filter for errors where the last request was to a specific service or ad network, or to segment errors where the last request status was not 200, in order to assist in identifying correlations. : Within web applications, bot traffic will likely be prevalent and might even trigger errors that end up in your Bugsnag inbox. Given that these events aren’t impacting a true user's experience and most bot traffic identifies itself in the agent string, some Bugsnag users check for bot traffic and add metadata to flag if a session is from a bot. This way, any exceptions linked to bot traffic can be excluded as part of your search parameters. Bot Traffic These concepts outline just some of the ways in which custom metadata allows you to track more precise segments of errors, and how to leverage them to both isolate visibility around revenue and ops situations, as well as to reduce noise. Focus in on Stability of Releases and Feature Flags One of our newest additions to Bugsnag is the Features dashboard, which provides actionable insights into stability of feature rollouts. One of the key functions within the Features dashboard is the Errors Introduced section, which highlights any errors that are exclusive to a specific feature flag or experiment. Our Releases dashboard also provides a similar Errors Introduced section, allowing developers to understand if there are errors unseen in any other version. The Features and Releases dashboards allow developers to quickly understand if a release version or feature needs to be rolled back to preserve stability, and if code within a feature or release is causing specific exceptions. Many Bugsnag users aren't aware that the search builder allows you to filter the inbox for errors exclusive to a certain release version or feature flag. We recommend creating a bookmark for errors introduced in the latest version and linking this to alerting, so that your team is notified of new errors brought on by your latest release. This can also be done for new features being rolled out to your user base. Our Releases dashboard typically becomes the command center for mobile teams and release managers in the days after their latest release, as this view provides the ability to monitor both stability and adoption by version number in real time. This dashboard can begin to hold quite a bit of data for web applications, that sometimes deploy hundreds of times per day. For web applications, we recommend that version is set , in order to plug in a more easily identifiable naming convention such as the Git SHA, or even a unique identifier based on the timestamp of the release. manually Some of our major eCommerce Bugsnag web users leverage this best practice to get stability by version as well as identify exclusive errors to specific versions. Callback Functions Let You Customize Error Data For most platforms and error types, valuable information can be accessed and changed via callback functions, which gives you access to the error data before the event is sent to Bugsnag. This helps teams do things like customize error grouping logic, add and change metadata or context based on breadcrumb properties, and even add additional information to tricky errors such as OOM errors in iOS. Information on callback functions for your platform can generally be found under the "Customizing error reports" section of our documentation. In addition to implementing many of the metadata ideas mentioned earlier within a callback, some powerful examples of leveraging callback functions are below: : Some Bugsnag users pull error information to determine the team responsible for an error. They are then able to add the responsible team’s name as custom metadata to simplify filtering errors by relevant squad in the dashboard. This logic can range from checking characteristics of the stackframe URL in web projects to pulling the module out of the path in iOS/Android. Determine responsible team : We've worked with iOS teams on pulling the last navigated-to page or view in a callback, in order to add more context on where in the app users are experiencing OOM errors. Bugsnag provides crucial information for OOM exceptions like breadcrumbs and metadata, and this can be leveraged to display the context of the OOM, as well as to group errors more precisely, so that you can track trends in OOMs in views or modules individually. In the example below, the callback function checks for relevant information in the breadcrumbs and uses this to change the OOM’s context and grouping hash. Setting Context and Custom Grouping Other Configuration Best Practices We've shared a lot of valuable examples of how to set up and customize Bugsnag to gain additional insight. Some configuration best practices we generally recommend to our users are below that can be simple to implement yet yield powerful results. By default, Bugsnag stores up to 50 breadcrumbs for each error, meaning that any additional user actions, device changes or network requests that are collected may start to drop off after the limit. Within the configuration, most platforms offer the option to adjust this to a true maximum of 100. If you are running into this limit in the dashboard, we recommend adjusting this maximum as needed in your code. Max Breadcrumb limit: For web applications, another important way to reduce noise is by configuring allowed domains. Bugsnag enables you to add your domain to a list of allowed domains in our settings, so you can automatically ignore any JavaScript errors that happen on other domains. This way, your dashboard can focus solely on the errors you know are coming from your own code and exclude any browser extensions or debugging scripts. We recommend setting this for web customers, and more details can be found in our Allowed Domains: documentation. An app hang (iOS) occurs when an instance of the main thread fails to respond in some amount of time - this can occur when performing CPU intensive work or performing blocking I/O on the main thread. If your app hangs for 10 seconds or longer, it may be terminated by the system watchdog, which is considered a fatal app hang. If your iOS team would like to also report non-fatal app hangs to Bugsnag as well, we recommend setting in the configuration to a value such as 5000ms. This allows you to gain visibility into performance issues that are not necessarily causing fatal crashes. Setting Max Milliseconds Parameter for App Hangs: appHangThresholdMillis

Unlocking Bugsnag's Power Features: Gain Precision and Reduce Noise

Welcome to other chapters of Let’s Understand Chrome V8 The bytecode is implemented using CodeStubAssembler (CSA), which can be roughly regarded as an assembly. Bytecode is loaded in a de-serialized manner during V8 startup, with no symbol table. So I want to tell you: CAS is obscure in a static analysis. Moreover, we can’t get the source code of the bytecode in debugging. This article will talk about how to debug bytecode at the assembly level and see its execution details. Figure 1 shows the interpreter of bytecodes. The figure is detailed enough for JavaScript developers. But for V8 learners, Figure 1 lacks a lot of detail, such as: the ignition startup, loading the bytecode, and dispatch. Let’s debug bytecode to dive into those details. 1. Preparation Before debugging, you’d better understand stack frames, the encoding of bytecodes and registers, . Note: see here Below is the Invoke which is the last C++ function before debugging. 1.  V8_WARN_UNUSED_RESULT MaybeHandle<Object> Invoke(Isolate* isolate,
2.                                                  const InvokeParams& params) {
3.   if (params.target->IsJSFunction()) {
4.  //............omit...............
5.   }
6.    Object value;
7.     Handle<Code> code =
8.         JSEntry(isolate, params.execution_target, params.is_construct);
9.     {
10.       SaveContext save(isolate);
11.       SealHandleScope shs(isolate);
12.       if (FLAG_clear_exceptions_on_js_entry) isolate->clear_pending_exception();
13.       if (params.execution_target == Execution::Target::kCallable) {
14.         using JSEntryFunction = GeneratedCode<Address(
15.             Address root_register_value, Address new_target, Address target,
16.             Address receiver, intptr_t argc, Address** argv)>;
17.         // clang-format on
18.         JSEntryFunction stub_entry =
19.             JSEntryFunction::FromAddress(isolate, code->InstructionStart());
20.         Address orig_func = params.new_target->ptr();
21.         Address func = params.target->ptr();
22.         Address recv = params.receiver->ptr();
23.         Address** argv = reinterpret_cast<Address**>(params.argv);
24.         RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::kJS_Execution);
25.         value = Object(stub_entry.Call(isolate->isolate_data()->isolate_root(),
26.                                        orig_func, func, recv, params.argc, argv));
27.       } else {
28.  //............omit...............
29.       }
30.     }
31.     //............omit...............
32.     return Handle<Object>(value, isolate);
33.   } Lines 14 to 23 initialize the JSFunction that will be executed, namely your JavaScript code. The following are five important members that you should remember. These members can help you to locate your position in debugging. They are constant in one debug context, but will be dissimilar in different debug. Line 7, , it is the Builtin::JSEntry pointer, now the value is 1FA 0E06 ED30 (In my debug context). (1) code Line 18, , it is the Ignition’s entrance. Below is the function that gets stub_entry from Builtin::JSEntry. (2) stub_entry Address Code::OffHeapInstructionStart() const {
  DCHECK(is_off_heap_trampoline());
  if (Isolate::CurrentEmbeddedBlob() == nullptr) return raw_instruction_start();
  EmbeddedData d = EmbeddedData::FromBlob();
  return d.InstructionStartOfBuiltin(builtin_index());
} The entry is 1FA 1326 1840. Line21, , it is the address of JSFunction, namely your JavaScript code. The value is 16 2BD8 15A9. (3) func The address of Builtin::InterpreterEntryTrampoline is 52 61C0 8A41. (4) The dispatch_table is 1FA 0E08 CFB0. (5) Figure 2 is the call stack that is going into bytecode. 2. Debug bytecode Let’s start to debug bytecode by stepping into stub_entry.Call(). I’m sorry I can’t go through the line-by-line since the assembly code doesn’t have context. I think the best way is to give the important states during the Ignition execution. In Figure 3, the register RCX is 1FA 1326 1840(stub_entry). As I mentioned, the stub_entry is the entrance of Ignition. In Figure 4, the register RBX is 1FA0E068A00 which is the first argument of stub_entry.Call(), that is isolate->isolate_data()->isolate_root(). Figure 5 is moving the R8 and calling RSI. The register R8 is func, and the RSI is stub_entry, below is the function to which the stub_entry is pointing. 1.  void Builtins::Generate_JSEntry(MacroAssembler* masm) {
2.    Generate_JSEntryVariant(masm, StackFrame::ENTRY,
3.                            Builtins::kJSEntryTrampoline);
4.  }
5.  //==================separation===========================
6.  void Generate_JSEntryVariant(MacroAssembler* masm, StackFrame::Type type,
7.                               Builtins::Name entry_trampoline) {
8.    Label invoke, handler_entry, exit;
9.    Label not_outermost_js, not_outermost_js_2;
10.    {  
11.      NoRootArrayScope uninitialized_root_register(masm);
12.      __ pushq(rbp);
13.      __ movq(rbp, rsp);
14.      __ Push(Immediate(StackFrame::TypeToMarker(type)));
15.      __ AllocateStackSpace(kSystemPointerSize);
16.      __ pushq(r12);
17.      __ pushq(r13);
18.      __ pushq(r14);
19.      __ pushq(r15);
20.  #ifdef _WIN64
21.      __ pushq(rdi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
22.      __ pushq(rsi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
23.  #endif
24.      __ pushq(rbx);
25.  #ifdef _WIN64 //Here is True, my OS is Win10!!!!!!!!!!!!!!!!!!
26.      // On Win64 XMM6-XMM15 are callee-save.
27.      __ AllocateStackSpace(EntryFrameConstants::kXMMRegistersBlockSize);
28.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 0), xmm6);
29.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 1), xmm7);
30.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 2), xmm8);
31.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 3), xmm9);
32.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 4), xmm10);
33.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 5), xmm11);
34.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 6), xmm12);
35.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 7), xmm13);
36.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 8), xmm14);
37.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 9), xmm15);
38.      STATIC_ASSERT(EntryFrameConstants::kCalleeSaveXMMRegisters == 10);
39.      STATIC_ASSERT(EntryFrameConstants::kXMMRegistersBlockSize ==
40.                    EntryFrameConstants::kXMMRegisterSize *
41.                        EntryFrameConstants::kCalleeSaveXMMRegisters);
42.  #endif
43.  //............omit...........................
44.  } In lines 12 to 37, we can see that they are the same as the assembly code in Figure 6. Actually, Generate_JSEntryVariant is executing. Builtin:JSEntry is responsible for organizing arguments by std::call standard. Later, the function Builtin::InterpreterEntryTrampoline will use these arguments. Builtin::InterpreterEntryTrampoline lookups at the dispatch_table to find the target bytecode and call it, shown in Figure 7. Let’s examine dispatch in a little more depth, see Figure 7. mark 1: the machine register R15 is the dispatch_table. mark 2: calculate the target bytecode address, that is dispatch_table + the encoding of the bytecode. mark 3: call the target bytecode. In my case, the target bytecode is LdaConstant. 1.  IGNITION_HANDLER(LdaConstant, InterpreterAssembler) {
2.    TNode<Object> constant = LoadConstantPoolEntryAtOperandIndex(0);
3.    SetAccumulator(constant);
4.    Dispatch();
5.  } When LdaConstant exits, lookup at the dispatch_table to find the next bytecode, shown in Figure 8. At the assembly level, we can see the Ignition startup and bytecode execution, which can help us understand the V8 interpreter better. Okay, that wraps it up for this share. I’ll see you guys next time, take care! Please reach out to me if you have any issues. : qq9123013 : WeChat Email v8blink@outlook.com

Let’s Understand Chrome V8 - Chapter 18: Understanding Bytecode and How to Debug it

As the blockchain sector continues to grow, new developments are taking place. Let's look at some interesting developments in the blockchain space. Decentralized applications are helping blockchain adoption There has been a proliferation of blockchain applications, which the advent of smart contracts may have driven. The term is often used in business to refer to digital agreements that expedite operational procedures. The terms of an agreement between two parties may be stored on a distributed ledger as a computer program if it is a smart contract. Electronic signatures are an option for all parties involved in this agreement. "smart contracts" Consequently, the agreement is irrevocable and cannot be modified by anyone. Furthermore, when certain conditions are met, smart contracts on the blockchain will automatically execute according to the terms they contain. This indicates that for the whole negotiation process, no third parties will be required to assist in bringing the two sides together and reaching a solution. Even businesses that do not have the resources to devote years to studying and constructing their very own blockchain network may still be able to reap the benefits of the accessibility afforded by smart contract algorithms that are based on blockchain technology. In addition, the current use of blockchain technology has made it possible to put into practice the algorithms behind smart contracts. Businesses may exploit the immutability of smart contracts by creating them on blockchains hosted by firms like Ethereum, Solana, and Cardano. This allows businesses to make use of the immutability of smart contracts. Companies might realize the advantages of such agreements in this manner. There are many ways in which the use of smart contracts can significantly enhance efficiency, including contexts in which there are several possible failure points. DFG and Jsquare lead $1.8 million in pre-seed funding for DAM Finance's cross-chain stablecoin dPRIME Asset Modules Finance (" DAM Finance" or "DAM"), a protocol for creating purchasing power from cross-chain token portfolios, recently closed a $1.8 million pre-seed funding round led by Digital Finance Group ("DFG") and . Jsquare DFG, a global blockchain, and cryptocurrency investment firm with more than $1 billion in assets under management, and Jsquare, a research and tech-driven investment firm focused on facilitating blockchain mass adoption, are joined by Arrington Capital, Ledgerprime, D1 Ventures, 11-11 Capital, Stacker Ventures and prominent angels within the Dotsama community as participants in the round. Funding will accelerate development towards DAM's mainnet launch, currently scheduled for later this year. DAM enables borrowers to deposit baskets of tokens in a single transaction to mint dPRIME, a Dotsama stablecoin on Moonbeam. This innovation provides borrowers more flexibility in purchasing power creation and vault maintenance while accommodating a broader range of blockchain-secured assets as collateral. Previously at firms such as R3, Myria, Fidelity, Oak Hill Capital, EY, and IC Group, the project's core contributors have backgrounds in enterprise and public blockchains, asset management, and data science. As a result, protocol risk management will be a major focus area for DAM. James Wo ( ), Founder and CEO of DFG, commented, "DFG is a strong backer of Polkadot and Kusama ecosystem, and DAM stands out from most of the multi-chain and cross-chain projects by showing its great competence in unlocking on-chain liquidity. We are also very confident about the coming launch of the dPRIME stablecoin. DFG will continuously support DAM to achieve a greater DeFi user experience." @realjameswo Joanna Liang ( ), Co-Founder and CEO of Jsquare, commented: @joanna_jsquare "As a research and tech-driven investment firm focused on facilitating blockchain mass adoption, we are excited to see DAM has the great potential to unlock liquidity from diversified token portfolios and create huge purchasing power for investors. It's an innovative design to increase the liquidity of the cross-chain long-tail assets. We're proud to be the leading investor to support the team to make it." Harrison Comfort ( ), Co-Founder and Product Lead of DAM, commented, "Our goal is to significantly improve upon the current DeFi borrowing experience by embracing the reality that web3 investors have increasingly diverse portfolios across multiple chains. We are fortunate to have a group of backers led by DFG and Jsquare that can help us realize our cross-chain vision while also supporting our strong emphasis on risk management." @hoco_dam The Metaverse is growing The concept of a virtual metaverse has piqued the curiosity of some major companies in the world. While it is unclear whether a centralized or decentralized metaverse will become the most popular option, both versions will certainly grow in popularity. When blockchain technology is used in the metaverse, it has the potential to be used to store user data on a tamper-proof, distributed ledger. This assures users that their data will not be changed. In addition, the blockchain ledgers' open verifiability will increase confidence in these freshly growing virtual worlds. The Sandbox and Decentraland are two examples of some of the most well-known blockchain-based metaverse projects already in development. Both hypothetical worlds are built on Ethereum, using the open architecture of the distributed computing platform to provide a trustworthy data environment for its inhabitants. Conclusion The cryptocurrency market grows and finds new uses as blockchain technology improves. Because of this, it is expected that the sector will continue to grow and change over time.

Interesting Developments Taking Place in the Crypto Space 

It is the final countdown!!! The Ethereum Merge is the biggest news in the crypto space right now. Everyone is talking about it, even Google is counting down to “The Merge” with a Doodle. Ethereum is set for this upgrade – one of the biggest upgrades in the industry. It can change everything. So, what is this Merge, and what will it do? Does this mean you have to move your ETH? Will the price of Ethereum increase? In this piece, I’ll explain what the Merge is and how it is expected to affect the Ethereum network. What is the Ethereum Merge? Think of it as the next-generation version of Ethereum. the whole process with this analogy: Ethereum Foundation itself explains “Imagine Ethereum is a spaceship that isn’t quite ready for an interstellar voyage. The community has built a new engine and a hardened hull with the Beacon Chain. After significant testing, it’s almost time to hot-swap the new engine for the old mid-flight. This will merge the new, more efficient engine into the existing ship, ready to put in some serious light years and take on the universe.” The upgrade will migrate the network from its Proof-of-Work (PoW) Consensus Model to a Proof-of-Stake (PoS) Model. (I’ll explain all about PoW and PoS soon). This will make the Blockchain 99% more energy efficient and drastically reduce its carbon footprint. It will also prepare the Ethereum Blockchain for future upgrades designed to make the Blockchain scalable and faster. The Merge is set to happen via two steps: Bellatrix and Paris. Bellatrix is the network upgrade on the network consensus, which already happened on the 6th of September. The next step, Paris, is the network transition from Proof-of-Work to Proof-of-Stake. This step will be triggered when the Total Difficulty Threshold reaches TTD (Terminal Total Difficulty), which is some hours from now. Before we continue, let’s talk about Proof-of-Work and Proof-Stake and how they work. So, you can understand what is going on better. Proof-of-Work Vs. Proof-of-Stake Proof-of-Work and Proof-of-Stake are to verify transactions and add new blocks to Blockchains. consensus mechanisms Blockchains use them to agree on things like the order of transactions, preventing users from double-spending. Each transaction can only have a single hash/nonce that will validate the transaction and create a new block. (To properly understand this process, you have to understand ). how a Blockchain works Proof-of-work involves computers racing to solve complex computational problems, find this hash/nonce, and validate transactions. That process is called “mining,” and each participating computer is a “miner.” It is similar to regular mining; however, you’re digging online for cryptocurrencies this time. The miner who first solves the complex problem and finds the nonce/hash is rewarded with a new crypto token (think of this as hitting gold!). It is called proof-of-work because you use real-world assets to confirm blocks and are rewarded with units of cryptocurrencies. In reality, PoW requires enormous amounts of electricity and computer power. On the other hand, Proof-of-Stake (PoS) doesn’t have miners; it involves validators or stackers. Instead of competing with powerful hardware, the validators or stakers contribute their capital (the crypto assets) in exchange for a chance to validate new transactions. You can think of the PoS as a less energy-intensive consensus model. It also reduces the risk of centralization by miners with more resources. What will the Ethereum Merge do? According to the Ethereum Foundation: “The Merge represents the joining of the existing execution layer of Ethereum (the Mainnet we use today) with its new proof-of-stake consensus layer, the Beacon Chain.” The current Genesis (Proof-of-Work) Layer is the Ethereum blockchain we know – it contains all transactions that have happened since July 2015. Genesis requires miners to validate each transaction through an energy-intensive process (Proof-of-Work). The problem is that this process consumes a lot of power and produces tons of carbon emissions. Currently, Ethereum , comparable to the yearly energy consumption of the Netherlands. The carbon footprint is at 53 MT/yr, similar to the carbon footprint of Hong Kong. consumes up to 112TWh/yr worth of power The process is energy-intensive and expensive, requiring miners to have sophisticated and costly hardware because of the competition. By moving to a Proof-of-stake consensus, the Ethereum network eliminates energy-intensive mining. The Beacon Chain, a Proof-of-Stake layer, will replace Genesis and switch out miners for validators. Estimation suggests that after the Merge, the Ethereum network will reduce its energy consumption by 99.95%, reducing the energy consumption to 0.01TWh/yr. What is the Beacon Chain? The Beacon Chain is the Proof-of-Stake layer or consensus “layer” on Ethereum. It has been running since November 2022 as a separate chain alongside the Ethereum Mainnet. The Beacon Chain uses validators instead of miners to validate transactions and form new blocks. In practice, you stake some ETH coins to activate the validator software and run the node software to become a validator. The node software processes new transactions and creates new blocks on the Blockchain. In turn, you get a percentage of the gas fee after validating transactions with your staked coins. The Merge will combine the Beacon chain with the existing execution layer, making it the new consensus engine. It will also signify the end of proof-of-work on the network. When will the Merge Happen? The Merge is happening soon – in just a few hours. The step is set to start when the Total Difficulty Threshold reaches TTD (Terminal Total Difficulty), which is some hours from now. What will Happen After the Merge? Validators will perform the same functions as Miners. But now, instead of competing with powerful hardware and energy consumptions, validators stake their ETH as collateral. According to Ethereum itself: The Merge represents the official switch to using the Beacon Chain as the engine of block production. Mining will no longer be the means of producing valid blocks. Instead, the proof-of-stake validators assume this role and will be responsible for processing the validity of all transactions and proposing blocks.” Here is a quick breakdown of what will happen after the Merge: The Beacon Chain proof of stake system merges with the Ethereum Mainnet. The end of Proof-of-work on the Ethereum network It will reduce Ethereum energy consumption by 99.5% It prepares the Ethereum Blockchain for the next set of upgrades Are there Further Upgrades to Follow the Merge? Yes. The Merge is Phase 1 of major upgrades coming to the Ethereum Blockchain in the coming years. These upgrades are expected to tackle the Blockchain’s scalability problem. The Upgrades are divided into 3 phases: The Beacon Chain (Phase 0) The Merge Sharding The upgrades are commonly referred to as The Merge, The Surge, The Verge, The Purge, and The Splurge. After all these upgrades, the Ethereum network is expected to become more secure, scalable, and sustainable. Scalability and security mean the network can better support Metaverse and Web 3. How will the Merge affect Ethereum Price? The Ethereum Foundation has clarified that the Merge will not directly impact Ethereum price. But there are several speculations about how the upgrade will affect the Ethereum price. You should expect the market price of Ethereum to react to the news. So, several traders, including Arthur Hayes, are bullish and expect the price to increase after the Merge. Arthur Hayes is the CEO of BitMex, a Crypto Trading Platform. He predicts that Ethereum should hit $3000 by December. Warning: Please note that these are only speculation. DYOR before making trading decisions. FAQs about the Merge Will the Merge reduce Gas Fees? No, according to the Ethereum Foundation: “The Merge is a change of consensus mechanism, not an expansion of network capacity, and will not result in lower gas fees.” Will the Merge Affect the Transaction speed? No. According to Ethereum: “A transaction’s “speed” can be measured in a few ways, including time to be included in a block and time to finalization. Both of these changes slightly, but not in a way that users will notice.” Will Eth2 replace ETH? No. After the Merge, there will not be two different networks. Eth2 will phase out and become Eth. The community adopted the terms Eth 1 and Eth 2 to limit confusion within the community. Eth1 – the execution layer Eth2 – the consensus layer You can read more about the naming . here How will the Merge Reduce Ethereum’s Carbon Footprint? BY transitioning to a Proof-of-Stake consensus model, The Merge will significantly reduce the resource to validate How will the Merge Affect the Ethereum Network? Do I have to Upgrade My ETH to Eth2? For general crypto users, the Merge will not affect the network. Nothing will happen to your Eth coins, and you don’t have to do anything. So, be careful of scams that will require you to upgrade to ETH2. There is no ETH2 token, and you don’t have to upgrade any token. The Ethereum Foundation puts out a warning: “As we approach The Merge of Ethereum Mainnet, you should be on high alert for scams trying to take advantage of users during this transition. Do not send your ETH anywhere in an attempt to “upgrade to ETH2.” There is no “ETH2” token, and there is nothing more you need to do for your funds to remain safe.”

Everything You Need To Know About the Ethereum Merge

Todo lo que necesita saber sobre la fusión de Ethereum

Tout ce que vous devez savoir sur la fusion Ethereum

एथेरियम मर्ज के बारे में आपको जो कुछ पता होना चाहिए

イーサリアムのマージについて知っておくべきことすべて

Tudo o que você precisa saber sobre a fusão do Ethereum

Mọi thứ bạn cần biết về hợp nhất Ethereum

关于以太坊合并你需要知道的一切

Execution is responsible for executing the bytecode. In this paper, we’ll talk about the workflow from S to E and several kernel functions. Our test case: function JsPrint(a){
	if(a >5){
		return "Debug";
	}
}
console.log(JsPrint(6)); Workflow The GetSharedFunctionInfoForScript() compiles JS source code into bytecodes. 0.  MaybeHandle<SharedFunctionInfo> Compiler::GetSharedFunctionInfoForScript(
1.      Isolate* isolate, Handle<String> source,
2.      const Compiler::ScriptDetails& script_details,
3.      ScriptOriginOptions origin_options, v8::Extension* extension,
4.      ScriptData* cached_data, ScriptCompiler::CompileOptions compile_options,
5.      ScriptCompiler::NoCacheReason no_cache_reason, NativesFlag natives) {
6.  //.omit.............
7.    // Do a lookup in the compilation cache but not for extensions.
8.    MaybeHandle<SharedFunctionInfo> maybe_result;
9.    IsCompiledScope is_compiled_scope;
10.    if (extension == nullptr) {
11.      bool can_consume_code_cache =
12.          compile_options == ScriptCompiler::kConsumeCodeCache;
13.      if (can_consume_code_cache) {
14.        compile_timer.set_consuming_code_cache();
15.      }
16.      // First check per-isolate compilation cache.
17.      maybe_result = compilation_cache->LookupScript(
18.          source, script_details.name_obj, script_details.line_offset,
19.          script_details.column_offset, origin_options, isolate->native_context(),
20.          language_mode);
21.      if (!maybe_result.is_null()) {
22.        compile_timer.set_hit_isolate_cache();
23.      } 
24.    }
25.  //.....omit..............
26.    if (maybe_result.is_null()) {
27.      ParseInfo parse_info(isolate);
28.      // No cache entry found compile the script.
29.      NewScript(isolate, &parse_info, source, script_details, origin_options,
30.                natives);
31.      // Compile the function and add it to the isolate cache.
32.      if (origin_options.IsModule()) parse_info.set_module();
33.      parse_info.set_extension(extension);
34.      parse_info.set_eager(compile_options == ScriptCompiler::kEagerCompile);
35.      parse_info.set_language_mode(
36.          stricter_language_mode(parse_info.language_mode(), language_mode));
37.      maybe_result = CompileToplevel(&parse_info, isolate, &is_compiled_scope);
38.      Handle<SharedFunctionInfo> result;
39.      if (extension == nullptr && maybe_result.ToHandle(&result)) {
40.        DCHECK(is_compiled_scope.is_compiled());
41.        compilation_cache->PutScript(source, isolate->native_context(),
42.                                     language_mode, result);
43.      } else if (maybe_result.is_null() && natives != EXTENSION_CODE) {
44.        isolate->ReportPendingMessages();
45.      }
46.    }
47.    return maybe_result;
48.  } In the 17th line of code, lookup compilation_cache, cache hit indicates that there are already bytecodes, and don’t need to recompile. The 26th line of code indicates that cache miss, so call the CompileToplevel on the 37th line to generate bytecodes. Bytecode needs to be bound to a context before execution, as below: 0.  Local<Script> UnboundScript::BindToCurrentContext() {
1.    auto function_info =
2.        i::Handle<i::SharedFunctionInfo>::cast(Utils::OpenHandle(this));
3.    i::Isolate* isolate = function_info->GetIsolate();
4.    i::Handle<i::JSFunction> function =
5.        isolate->factory()->NewFunctionFromSharedFunctionInfo(
6.            function_info, isolate->native_context());
7.    return ToApiHandle<Script>(function);
8.  } After binding, we get an important member — JSFunction, which is the input expected by the execution. 0.  bool Shell::ExecuteString(Isolate* isolate, Local<String> source,
1.                            Local<Value> name, PrintResult print_result,
2.                            ReportExceptions report_exceptions,
3.                            ProcessMessageQueue process_message_queue) {
4.    bool success = true;
5.    {
6.      PerIsolateData* data = PerIsolateData::Get(isolate);
7.      Local<Context> realm =
8.          Local<Context>::New(isolate, data->realms_[data->realm_current_]);
9.      Context::Scope context_scope(realm);
10.      MaybeLocal<Script> maybe_script;
11.      Local<Context> context(isolate->GetCurrentContext());
12.      ScriptOrigin origin(name);
13.      if (options.compile_options == ScriptCompiler::kConsumeCodeCache) {
14.  //.......omit
15.      } else if (options.stress_background_compile) {
16.  //.......omit
17.      } else {
18.        ScriptCompiler::Source script_source(source, origin);
19.        maybe_script = ScriptCompiler::Compile(context, &script_source,
20.                                               options.compile_options);
21.      }
22.      maybe_result = script->Run(realm);
23.  //......omit
24.      if (options.code_cache_options ==
25.          ShellOptions::CodeCacheOptions::kProduceCacheAfterExecute) {
26.        // Serialize and store it in memory for the next execution.
27.        ScriptCompiler::CachedData* cached_data =
28.            ScriptCompiler::CreateCodeCache(script->GetUnboundScript());
29.        StoreInCodeCache(isolate, source, cached_data);
30.        delete cached_data;
31.      }
32.      if (process_message_queue && !EmptyMessageQueues(isolate)) success = false;
33.      data->realm_current_ = data->realm_switch_;
34.    }
35.    DCHECK(!try_catch.HasCaught());
36.    return success;
37.  } The above function is the entrance for executing JS. Line 19 compiles the JS to bytecode. Line 22 executes the bytecode. Debug line 22 to step into the Run(realm). 0.  MaybeLocal<Value> Script::Run(Local<Context> context) {
1.    auto isolate = reinterpret_cast<i::Isolate*>(context->GetIsolate());
2.    TRACE_EVENT_CALL_STATS_SCOPED(isolate, "v8", "V8.Execute");
3.    ENTER_V8(isolate, context, Script, Run, MaybeLocal<Value>(),
4.             InternalEscapableScope);
5.    i::HistogramTimerScope execute_timer(isolate->counters()->execute(), true);
6.    i::AggregatingHistogramTimerScope timer(isolate->counters()->compile_lazy());
7.    i::TimerEventScope<i::TimerEventExecute> timer_scope(isolate);
8.    auto fun = i::Handle<i::JSFunction>::cast(Utils::OpenHandle(this));
9.    i::Handle<i::Object> receiver = isolate->global_proxy();
10.    Local<Value> result;
11.    has_pending_exception = !ToLocal<Value>(
12.        i::Execution::Call(isolate, fun, receiver, 0, nullptr), &result);
13.    RETURN_ON_FAILED_EXECUTION(Value);
14.    RETURN_ESCAPED(result);
15.  } The 8th line casts this pointer to JSFunction. For our case, the variable fun is console.log(JsPrint(6)), then call the 12th line — call(). In call(), the Invoke() will be called which is below. 0.  V8_WARN_UNUSED_RESULT MaybeHandle<Object> Invoke(Isolate* isolate,
1.                                                   const InvokeParams& params) {
2.  //...............omit
3.    Object value;
4.    Handle<Code> code =
5.        JSEntry(isolate, params.execution_target, params.is_construct);
6.    {
7.      SaveContext save(isolate);
8.      SealHandleScope shs(isolate);
9.      if (FLAG_clear_exceptions_on_js_entry) isolate->clear_pending_exception();
10.      if (params.execution_target == Execution::Target::kCallable) {
11.        // clang-format off
12.        // {new_target}, {target}, {receiver}, return value: tagged pointers
13.        // {argv}: pointer to array of tagged pointers
14.        using JSEntryFunction = GeneratedCode<Address(
15.            Address root_register_value, Address new_target, Address target,
16.            Address receiver, intptr_t argc, Address** argv)>;
17.        // clang-format on
18.        JSEntryFunction stub_entry =
19.            JSEntryFunction::FromAddress(isolate, code->InstructionStart());
20.        Address orig_func = params.new_target->ptr();
21.        Address func = params.target->ptr();
22.        Address recv = params.receiver->ptr();
23.        Address** argv = reinterpret_cast<Address**>(params.argv);
24.        RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::kJS_Execution);
25.        value = Object(stub_entry.Call(isolate->isolate_data()->isolate_root(),
26.                                       orig_func, func, recv, params.argc, argv));
27.      } else {
28.  //..................omit     
29.      }
30.    } Line 18 gets the address of the builtin, its index is 40, and its name is JSEntry. This builtin builds the execution environment for bytecodes. Then step into line 25, where the bytecode is executed. After that, we can only debug the assembly code, but c++. Figure 1 is the call stack. Before stepping into bytecodes, Generate_JSEntryVariant will be called. 0.  void Generate_JSEntryVariant(MacroAssembler* masm, StackFrame::Type type,
1.                               Builtins::Name entry_trampoline) {
2.    Label invoke, handler_entry, exit;
3.    Label not_outermost_js, not_outermost_js_2;
4.    {  // NOLINT. Scope block confuses linter.
5.      NoRootArrayScope uninitialized_root_register(masm);
6.      // Set up frame.
7.      __ pushq(rbp);
8.      __ movq(rbp, rsp);
9.      // Push the stack frame type.
10.      __ Push(Immediate(StackFrame::TypeToMarker(type)));
11.      // Reserve a slot for the context. It is filled after the root register has
12.      // been set up.
13.      __ AllocateStackSpace(kSystemPointerSize);
14.      // Save callee-saved registers (X64/X32/Win64 calling conventions).
15.      __ pushq(r12);
16.      __ pushq(r13);
17.      __ pushq(r14);
18.      __ pushq(r15);
19.  #ifdef _WIN64
20.      __ pushq(rdi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
21.      __ pushq(rsi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
22.  #endif
23.      __ pushq(rbx);
24.  //.....................omit............................
25.    __ ret(0);
26.  }
27.  }  // namespace
28.  //==================separation===============================
29.  void Builtins::Generate_JSEntry(MacroAssembler* masm) {
30.    Generate_JSEntryVariant(masm, StackFrame::ENTRY,
31.                            Builtins::kJSEntryTrampoline);
32.  } Look at the 30th line of code, the generator function of the 40th builtin is B, and its analysis method refers to my previous paper. Figure 2 shows the corresponding assembly code. You can also see a bit of C++ in Figure 2, but this is the last chance to see C++. After that, only the assembly code. Our case uses the console.log which is a global function. It is below. 1.  #define RUNTIME_FUNCTION_RETURNS_TYPE(Type, InternalType, Convert, Name)      \
2.    static V8_INLINE InternalType __RT_impl_##Name(Arguments args,              \
3.                                                   Isolate* isolate);           \
4.                                                                                \
5.    V8_NOINLINE static Type Stats_##Name(int args_length, Address* args_object, \
6.                                         Isolate* isolate) {                    \
7.      RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::k##Name);      \
8.      TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("v8.runtime"),                     \
9.                   "V8.Runtime_" #Name);                                        \
10.     Arguments args(args_length, args_object);                                 \
11.      return Convert(__RT_impl_##Name(args, isolate));                          \
12.    }                                                                           \
13.                                                                                \
14.    Type Name(int args_length, Address* args_object, Isolate* isolate) {        \
15.      DCHECK(isolate->context().is_null() || isolate->context().IsContext());   \
16.      CLOBBER_DOUBLE_REGISTERS();                                               \
17.      if (V8_UNLIKELY(TracingFlags::is_runtime_stats_enabled())) {              \
18.        return Stats_##Name(args_length, args_object, isolate);                 \
19.      }                                                                         \
20.      Arguments args(args_length, args_object);                                 \
21.      return Convert(__RT_impl_##Name(args, isolate));                          \
22.    }                                                                           \
23.                                                                                \
24.    static InternalType __RT_impl_##Name(Arguments args, Isolate* isolate)
25.  #define CONVERT_OBJECT(x) (x).ptr()
26.  #define CONVERT_OBJECTPAIR(x) (x)
27.  #define RUNTIME_FUNCTION(Name) \
28.    RUNTIME_FUNCTION_RETURNS_TYPE(Address, Object, CONVERT_OBJECT, Name)
29.  //=================separation==============================
30.  //==================separation===============================
31.  Object DeclareGlobals(Isolate* isolate, Handle<FixedArray> declarations,
32.                        int flags, Handle<JSFunction> closure) {
33.    HandleScope scope(isolate);
34.    Handle<JSGlobalObject> global(isolate->global_object());
35.    Handle<Context> context(isolate->context(), isolate);
36.    Handle<FeedbackVector> feedback_vector = Handle<FeedbackVector>::null();
37.    Handle<ClosureFeedbackCellArray> closure_feedback_cell_array =
38.        Handle<ClosureFeedbackCellArray>::null();
39.    if (closure->has_feedback_vector()) {
40.      feedback_vector =
41.          Handle<FeedbackVector>(closure->feedback_vector(), isolate);
42.      closure_feedback_cell_array = Handle<ClosureFeedbackCellArray>(
43.          feedback_vector->closure_feedback_cell_array(), isolate);
44.    } else {
45.      closure_feedback_cell_array = Handle<ClosureFeedbackCellArray>(
46.          closure->closure_feedback_cell_array(), isolate);
47.    }
48.    // Traverse the name/value pairs and set the properties.
49.    int length = declarations->length();
50.    FOR_WITH_HANDLE_SCOPE(isolate, int, i = 0, i, i < length, i += 4, {
51.      Handle<String> name(String::cast(declarations->get(i)), isolate);
52.      FeedbackSlot slot(Smi::ToInt(declarations->get(i + 1)));
53.      Handle<Object> possibly_feedback_cell_slot(declarations->get(i + 2),
54.                                                 isolate);
55.      Handle<Object> initial_value(declarations->get(i + 3), isolate);
56.      bool is_var = initial_value->IsUndefined(isolate);
57.      bool is_function = initial_value->IsSharedFunctionInfo();
58.      DCHECK_NE(is_var, is_function);
59.      Handle<Object> value;
60.      if (is_function) {
61.        DCHECK(possibly_feedback_cell_slot->IsSmi());
62.        Handle<FeedbackCell> feedback_cell =
63.            closure_feedback_cell_array->GetFeedbackCell(
64.                Smi::ToInt(*possibly_feedback_cell_slot));
65.        // Copy the function and update its context. Use it as value.
66.        Handle<SharedFunctionInfo> shared =
67.            Handle<SharedFunctionInfo>::cast(initial_value);
68.        Handle<JSFunction> function =
69.            isolate->factory()->NewFunctionFromSharedFunctionInfo(
70.                shared, context, feedback_cell, AllocationType::kOld);
71.        value = function;
72.      } else {
73.        value = isolate->factory()->undefined_value();
74.      }
75.      // Compute the property attributes. According to ECMA-262,
76.      // the property must be non-configurable except in eval.
77.      bool is_eval = DeclareGlobalsEvalFlag::decode(flags);
78.      int attr = NONE;
79.      if (!is_eval) attr |= DONT_DELETE;
80.      // ES#sec-globaldeclarationinstantiation 5.d:
81.      // If hasRestrictedGlobal is true, throw a SyntaxError exception.
82.      Object result = DeclareGlobal(isolate, global, name, value,
83.                                    static_cast<PropertyAttributes>(attr), is_var,
84.                                    is_function, RedeclarationType::kSyntaxError,
85.                                    feedback_vector, slot);
86.      if (isolate->has_pending_exception()) return result;
87.    });
88.    return ReadOnlyRoots(isolate).undefined_value();
89.  }
90.  //==================separation===============================
91.  //==================separation===============================
92.  RUNTIME_FUNCTION(Runtime_DeclareGlobals) {
93.    HandleScope scope(isolate);
94.    DCHECK_EQ(3, args.length());
95.    CONVERT_ARG_HANDLE_CHECKED(FixedArray, declarations, 0);
96.    CONVERT_SMI_ARG_CHECKED(flags, 1);
97.    CONVERT_ARG_HANDLE_CHECKED(JSFunction, closure, 2);
98.    return DeclareGlobals(isolate, declarations, flags, closure);
99.  } RUNTIME_FUNCTION(Runtime_DeclareGlobals) is a runtime function defined by a macro template. The function checks the parameters and then calls DeclareGlobals() to perform the corresponding operation. In our case, DeclareGlobals() lookup the global object console, then takes out the log() from the console, and gets the address of console.log(). Finally, pass the parameter JsPrint(6) into log() which will start a new compilation and execution. Okay, that wraps it up for this share. I’ll see you guys next time, take care! Please reach out to me if you have any issues. : qq9123013 : v8blink@outlook.com WeChat Email This story was first published here.

Stories, News & Mentions about STACKERA

Stackera’s Stories on HackerNoon