OneApp

Regulators are circling above wishing death upon Cryptos; To survive, cryptos must come to a compromise where Centralized Finance ala Traditional banking and Decentralized Finance (DeFi) co-exist, and regulators have a say, yet the anonymity of the blockchain is preserved. This is what the immediate Future of Finance is likely to look like. …no amount of run will render  a Bank Alternative insolvent These parallel financial silos become one entity linked together by bridges. They are different from traditional finance/banking and also unlike decentralized finance; it is a hybrid, an alternative. For the purpose of this paper we would call it A Bank Alternative A Bank Alternative A bank Alternative will take the best of traditional Banking/Finance, put them in digital form, and bridge them with Decentralized finance, in such a way that you can enjoy the benefits of the two financial worlds from the same app seamlessly. Like a Fintech and DeFi having a lovechild. A Bank Alternative is different from traditional banking because it does not practice fractional banking, and different from DeFi because it does not use stablecoins rather it uses Digital cash which is real-money on-chain (like e-money or Private CBDC) and each digital cash is 100% backed by real money in a 1:1 ratio held in treasury and verifiable on-chain. This ensures that no amount of run will render a Bank Alternative insolvent, because all its cash and digital cash are represented by cash held in treasury in a 1:1 ratio. You will always get 1Dollar for every Dollar in your bank account or Digital-Dollar held in your Digital Account every time and anytime. A Bank Alternative is run-proof. It generates revenue from fees. A Bank Alternative will give you at least two accounts. One is like a traditional bank account for your fiat currency (in digital form), and the other is a digital account/wallet more appropriate for Web3, Digital assets, and cryptocurrencies. Both allow you to move in-between them seamlessly and by implication change the state of your money/asset permissionlessly. Many banks and Centralized exchanges (CEX) are looking at becoming a Bank Alternative Ah! Tax A Bank Alternative is primarily built on blockchain, however, all its centralized activities not verifiable on-chain would be regulated. And all decentralized finance activities verifiable on-chain would remain unregulated, making it easier to tax the off-chain regulated items for starters. This is a pragmatic first-step The Regulatory Hurdle The road to Bank Alternatives is filled with regulatory challenges from both the State and the financial regulators. Many countries have out rightly banned cryptocurrency like China, Bolivia, Ghana, etc and then there are countries where it is restricted including Turkey, Saudi Arabia, Nigeria, etc. The restrictions will have to be relaxed before a Bank Alternative can fully blossom Who Will Become A Bank Alternatives Many banks and Centralized exchanges (CEX) are looking at becoming Bank Alternatives but the regulatory hurdles keep them at bay. Fintech seems better position to become Bank Alternatives; in this group, you will find Revolut and MoneyGram + Stellar. However, in the true tenets and structure of a Bank Alternative, as described above, you will find only and . Only Fluid is active and has launched an App on Arbitrum that is working in true Bank Alternative. Yes, it’s early days, and many more features to come but this is the Bank Alternative. Fluid Finance Hightop If you stay traditional you will be left behind as the internet left AOL In Conclusion: The Future For Banks and DeFi is The Bank Alternative This middle-ground solution is where all Banks and DeFi must meet in other to survive. According to Robert Sharratt “If you stay traditional you will be left behind as the internet left AOL”; I translate this to mean, if you refuse to compromise as a DeFi-playing around with traditional financial services, the regulators will ensure you remain in the financial wasteland where all unregulated are sent to die. Disclosure Although, I do not work for Fluid Finance SA, I have had a financial relationship with fluid finance. This statement is intended to disclose any conflict of interest. Disclaimer The opinions shared within this article are solely those of the authors. Note that the content within should not be considered financial, legal, or tax advice. Neither the author nor Fluid Finance is a financial, legal, or tax advisor. Do your own research and consult professionals as needed for official policies, restrictions, and requirements in your jurisdiction.

Two Financial Worlds One App

Is it possible to unify all communication apps into one? There has been a recent influx of communication apps which have promptly taken the world by storm, and I for one am a bit overwhelmed. As we have evolved from , these mystical gadgets have spawned the growth of apps. These apps have exceeded anything the creators of the smartphone could have ever fathomed, and now we are experiencing sensory overload. flip phones to smartphones Let me run you through a typical day, and you tell me if it sounds familiar. 7 am — I wake up and check Slack to see if anyone on my team pinged me, as well as look at my messages (WhatsApp, Facebook Messenger, etc.) Then, I check Intercom to make sure there aren’t any customer requests I missed while I was sleeping. Next, I go on to catch up on my email before I start the day. Finally, I browse through all of my social media accounts to see if anyone has tried to correspond with me through there. 10 am — I finish stand up with the team and go through the same process as when I woke up. This time, I have more messages and emails to respond to which compiled from the morning to now. Throughout the day — I continue with this process to keep my head above water. This process involves me checking Slack, HipChat, Snapchat, WhatsApp, WeChat, iMessage, Intercom, Facebook, Facebook Messenger, Twitter, Instagram, Pinterest, LinkedIn, Medium, Viber, Kik, Skype, Line, Hike, Google Hangouts, and other apps constantly. This is nonstop for me. Rest of my day — I repeat this process, during which - I use every waking moment to keep up with the conversation I so desperately need to participate in. These events unfold during a typical day for me, and I know I am not the only one who goes through this. I believe this is normal for a number of people. An obvious way to overcome the problem at hand would be for me not to participate in so many conversations. The proposed solution may not bode so well for me, seeing I need those conversations to keep things running. A more practical solution would be to develop an app which unifies all communication methods and combines it into one. If I could utilize one app for all of my communication needs, my life would be a breeze (or at least a bit simpler). For this reason and this reason alone, I have decided to . develop an app which caters to the problem at hand will combine all forms of communication into one simple application to both digest and send messages and emails from a central location. The app I am developing I am currently in the early stages of development for my unified messaging platform, which I have named . UNUM messenger I plan to launch in March of 2017 as a Beta. If you would like to be notified when launches, you can sign up to do so . UNUM messenger UNUM messenger here If you would like to follow me on my journey, be sure to follow me . Also, If you liked this article be sure to like it! here on Medium

One App To Rule Them All

Authors:
(1) Vinod S. Khandkar and Manjesh K. Hanawal, Industrial Engineering and Operations Research Indian Institute of Technology Bombay, Mumbai, India and {vinod.khandkar, mhanawal}@iitb.ac.in. Table of Links Abstract & Introduction Related Work and Background Challenges in TD Detection Measurement Setup Development Case Study : Wehe - TD Detection Tool for Mobile Environment Shortcoming of Wehe on HTTPS Traffic TD Detection of HTTPS Traffic Conclusion & References IV. CASE STUDY : WEHE - TD DETECTION TOOL FOR MOBILE ENVIRONMENT Wehe [13] is a tool for the detection of traffic differentiation over mobile networks (e.g., cellular and WiFi). It is available as an App on Android and the iOS platform. The user database of the Wehe tool consists of 126,249 users across 2,735 ISPs in 183 countries/regions generating 1,045,413 crowd-sourced measurements. European national telecom regulator, the US FTC and FCC, US Senators, and numerous US state legislators have used the Wehe tool’s findings. The tool supports TD detection for many popular services such as Netflix, YouTube. The tool runs TD detection tests by coordinating with its server, called the “replay server”. The replay server keeps track of active users and maps replay runs to the correct user’s service. A. Traffic generation Wehe uses the “record-and-replay” method for generating probing traffic. The user-client exchanges the probing traffic with the replay server as per the replay script that captures the application-level traffic behavior, including the port number, data sequence, and timing dependencies from the original service’s network logs. Preserving timing is a crucial feature of Wehe’s approach. It expects network devices to use this information in case of non-availability of any other means to classify applications, e.g., HTTPS encrypted data transfer Wehe tool uses two types of probing traffic streams. While one stream (original replay) is the same as the original service’s application-level network trace, another traffic stream (control replay) differs substantially from the first traffic stream. In one approach, Wehe uses the VPN channel to send a second probing traffic stream. This approach uses the meddle VPN [30] framework for data transfer and server-side packet capture. Another approach uses the bit-reversed version of the first traffic stream sent one the same channel. Currently, Wehe uses the latter approach due to its superior results. B. Over the network response Wehe is a differential detector tool that compares the network responses for two types of traffic streams generated by the tool. The service-specific information present in the original replay is useful for network devices with Deep Packet Inspection (DPI) capability to identify and classify the service correctly. So, the original replay’s traffic performance over the Internet closely resembles the original application traffic on the same network. While original replay is exposed for detection to network devices, the traffic streams with bit reversed data or control replay is equally “not detectable” for classification. Thus it is expected that the control replay traffic evades the content-based application-specific traffic differentiation. The performances of two such traffic streams (detectable and nondetectable) differ if network devices apply different traffic management or traffic differentiation on each traffic stream as per content-based classification. C. TD detection scenario expectations Wehe compares the throughput performances of original replay and control replay to detect TD. The methodology uses the throughput as a comparison metric due to its sensitivity to bandwidth-limiting traffic shaping. However, the tool expects that the TD detection algorithm does not detect TD based on throughput for traffic streams with traffic rates below the shaping rate. The rationale is that the shaper cannot affect the performance of such an application stream. Many times both traffic streams get affected by other factors such as signal strength, congestion. It creates an irregularity in the received performance due to bandwidth volatility. It is mentioned to be leading to incorrect differentiation detection. The tool performs multiple test replays to overcome the effect of bandwidth volatility. D. Operational requirements Wehe server needs side-channels for each client to associate it with precisely one app replay. This side-channel supplies information about replay runs to the server. Each user directly connected to the Wehe replay server is uniquely identifiable on the server-side with an associated IP address of side channels that maps each replay to exactly one App. The other operational requirement is that the Wehe clientserver communication uses customized socket connections with specific keep-alive behavior. Sometimes, the usage of translucent proxies by the user-client modifies this behavior. The Replay server handles this situation by handling such unexpected connections. The protocol-specific proxies, e.g., HTTP proxy, connect the user-client to the server through itself using specific port numbers, e.g., 80/443 for HTTP/HTTPS. Nevertheless, it allows the user-client to connect to the server for connections using other protocols directly. The side channels of Wehe do not use HTTP/HTTPS connections. So the IP address for the same user differs for side-channel and replay runs. Wehe server detects such connections and indicates such connections to the user-client using a special message. The special message triggers the exchange of further communication with a customized header. E. Challenges of validating Wehe The TD mechanism of Wehe is straightforward to use — the requirement changes when using it for its validation. The validation process may need to launch only one type of replay for different services during one test or may need to launch all replays in parallel. These are not requirements related to TD detection, Wehe’s primary goal, so understandably not supported. Hence the validation of Wehe’s working in such scenarios needs a specific client-server setup. Here the challenge is to separate the intended scenario-specific Wehe’s mechanism so that the resulting system still mimics Wehe’s actual behavior. Moreover, Wehe does not provide error/failure notifications in all scenarios. Instead, it prompts the user to reopen the App. As a result, the validation setup loses vital feedback information regarding the error/failure induced by its validation scenario. This paper is available on arxiv under CC 4.0 license. Authors: (1) Vinod S. Khandkar and Manjesh K. Hanawal, Industrial Engineering and Operations Research Indian Institute of Technology Bombay, Mumbai, India and {vinod.khandkar, mhanawal}@iitb.ac.in. Authors: Authors: (1) Vinod S. Khandkar and Manjesh K. Hanawal, Industrial Engineering and Operations Research Indian Institute of Technology Bombay, Mumbai, India and {vinod.khandkar, mhanawal}@iitb.ac.in. Table of Links Abstract & Introduction Abstract & Introduction Related Work and Background Related Work and Background Challenges in TD Detection Measurement Setup Development Challenges in TD Detection Measurement Setup Development Case Study : Wehe - TD Detection Tool for Mobile Environment Case Study : Wehe - TD Detection Tool for Mobile Environment Shortcoming of Wehe on HTTPS Traffic Shortcoming of Wehe on HTTPS Traffic TD Detection of HTTPS Traffic TD Detection of HTTPS Traffic Conclusion & References Conclusion & References IV. CASE STUDY : WEHE - TD DETECTION TOOL FOR MOBILE ENVIRONMENT Wehe [13] is a tool for the detection of traffic differentiation over mobile networks (e.g., cellular and WiFi). It is available as an App on Android and the iOS platform. The user database of the Wehe tool consists of 126,249 users across 2,735 ISPs in 183 countries/regions generating 1,045,413 crowd-sourced measurements. European national telecom regulator, the US FTC and FCC, US Senators, and numerous US state legislators have used the Wehe tool’s findings. The tool supports TD detection for many popular services such as Netflix, YouTube. The tool runs TD detection tests by coordinating with its server, called the “replay server”. The replay server keeps track of active users and maps replay runs to the correct user’s service. A. Traffic generation A. Traffic generation Wehe uses the “record-and-replay” method for generating probing traffic. The user-client exchanges the probing traffic with the replay server as per the replay script that captures the application-level traffic behavior, including the port number, data sequence, and timing dependencies from the original service’s network logs. Preserving timing is a crucial feature of Wehe’s approach. It expects network devices to use this information in case of non-availability of any other means to classify applications, e.g., HTTPS encrypted data transfer Wehe tool uses two types of probing traffic streams. While one stream (original replay) is the same as the original service’s application-level network trace, another traffic stream (control replay) differs substantially from the first traffic stream. In one approach, Wehe uses the VPN channel to send a second probing traffic stream. This approach uses the meddle VPN [30] framework for data transfer and server-side packet capture. Another approach uses the bit-reversed version of the first traffic stream sent one the same channel. Currently, Wehe uses the latter approach due to its superior results. B. Over the network response B. Over the network response Wehe is a differential detector tool that compares the network responses for two types of traffic streams generated by the tool. The service-specific information present in the original replay is useful for network devices with Deep Packet Inspection (DPI) capability to identify and classify the service correctly. So, the original replay’s traffic performance over the Internet closely resembles the original application traffic on the same network. While original replay is exposed for detection to network devices, the traffic streams with bit reversed data or control replay is equally “not detectable” for classification. Thus it is expected that the control replay traffic evades the content-based application-specific traffic differentiation. The performances of two such traffic streams (detectable and nondetectable) differ if network devices apply different traffic management or traffic differentiation on each traffic stream as per content-based classification. C. TD detection scenario expectations C. TD detection scenario expectations Wehe compares the throughput performances of original replay and control replay to detect TD. The methodology uses the throughput as a comparison metric due to its sensitivity to bandwidth-limiting traffic shaping. However, the tool expects that the TD detection algorithm does not detect TD based on throughput for traffic streams with traffic rates below the shaping rate. The rationale is that the shaper cannot affect the performance of such an application stream. Many times both traffic streams get affected by other factors such as signal strength, congestion. It creates an irregularity in the received performance due to bandwidth volatility. It is mentioned to be leading to incorrect differentiation detection. The tool performs multiple test replays to overcome the effect of bandwidth volatility. D. Operational requirements D. Operational requirements Wehe server needs side-channels for each client to associate it with precisely one app replay. This side-channel supplies information about replay runs to the server. Each user directly connected to the Wehe replay server is uniquely identifiable on the server-side with an associated IP address of side channels that maps each replay to exactly one App. The other operational requirement is that the Wehe clientserver communication uses customized socket connections with specific keep-alive behavior. Sometimes, the usage of translucent proxies by the user-client modifies this behavior. The Replay server handles this situation by handling such unexpected connections. The protocol-specific proxies, e.g., HTTP proxy, connect the user-client to the server through itself using specific port numbers, e.g., 80/443 for HTTP/HTTPS. Nevertheless, it allows the user-client to connect to the server for connections using other protocols directly. The side channels of Wehe do not use HTTP/HTTPS connections. So the IP address for the same user differs for side-channel and replay runs. Wehe server detects such connections and indicates such connections to the user-client using a special message. The special message triggers the exchange of further communication with a customized header. E. Challenges of validating Wehe E. Challenges of validating Wehe The TD mechanism of Wehe is straightforward to use — the requirement changes when using it for its validation. The validation process may need to launch only one type of replay for different services during one test or may need to launch all replays in parallel. These are not requirements related to TD detection, Wehe’s primary goal, so understandably not supported. Hence the validation of Wehe’s working in such scenarios needs a specific client-server setup. Here the challenge is to separate the intended scenario-specific Wehe’s mechanism so that the resulting system still mimics Wehe’s actual behavior. Moreover, Wehe does not provide error/failure notifications in all scenarios. Instead, it prompts the user to reopen the App. As a result, the validation setup loses vital feedback information regarding the error/failure induced by its validation scenario. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Wehe: Hacking Traffic Differentiation Detection for Mobile Environments

Annually, worldwide turn to ride-hailing apps for transportation, with Russia alone accounting for more than 2.5 billion rides per year. The responsibility of matching each passenger with the ideal driver for every trip falls squarely on the shoulders of the ride-hailing service. over 1.4 billion people So, how do market leaders tackle this complex task? By processing gigabytes of real-time data and deploying algorithms, including those based on machine learning, they ensure the passenger is paired with the most suitable driver. At a high level, the process involves several critical steps: But how exactly are all these data points synthesized? Gathering all available drivers in the vicinity. Filtering out those who are not currently available, for instance, drivers who are in an 'unavailable' status or those who do not meet the class criteria (such as Economy drivers for a Comfort ride). Ranking the remaining drivers based on known factors, such as their proximity to the pickup location, their intended direction, and their tendency to accept rides with a similar profile. aggregating nearby orders for a period and then intelligently redistributing drivers among these orders to ensure each one receives the best match. This strategy enables companies to allocate drivers in under half a minute, significantly reducing the wait time for clients. The next step involves batching: However, this level of efficiency is only achievable when you have: Drivers, Data about them, An effective algorithm. During my tenure at one of the world's leading taxi services, I served as a Product Manager in the Marketplace domain. My primary responsibilities revolved around ensuring client reliability and maximizing company profits, which were the key objectives. In this capacity, I oversaw partner integrations as a product and optimized supply allocation logic using machine learning tools. Let's go! Optimizing Reliability and Efficiency in the UK Taxi Market with ML The platform in the UK was launched in 2019. Each time we launched, we had to configure the setup in one way or another. Overall, it worked out for us: we achieved acceptable reliability figures (in the ride-hailing market, the main reliability metric usually represents the ratio of successfully completed rides to all customer orders). However, in many cases, our decisions were more "expertise-based" than data-driven: we relied on the knowledge of mobility platform staff to advise on the strengths of each partner. It was wonderful to see our unique value proposition actually working, being used by customers, and generating revenue. Nevertheless, the company had already gained experience in driver matching, and we knew we could optimize the ride exchange market. So, our ML engineers were put to work, and the results were encouraging: every key metric, on average, increased by 5%. It was also surprising to see how incorrectly some of our configurations had been set up before. Even though we were operating in two entirely different markets (more on the Russian experience below), the pattern repeated. There was still room for improvement by gradually fine-tuning the weights of features, introducing new features, or discarding some. However, some areas (remote cities or just places where the immobility platform does not have a strong customer base) had to remain under manual control. Yet, the "Ride Exchange platform" became smarter, more reliable, and cost-efficient. Not to mention, we became the first in the world to create a market of fully integrated transportation services for customers in one app, and also the first to power it with ML. The main metric for us is the percentage of satisfied customers who booked a ride and eventually took a ride to their desired destination (GC/GCR – Gross Completion Rate). Since the launch, I have experienced a lot with the platform and learned many lessons. Some of them include: Finding the right balance in the historical depth of data to account for both recent data about the supplier (from the last 24 hours) and the averages over the last three months. Understanding which features will be useful, and which will not? There are two ways to answer this: by conducting a simulation and/or a real experiment. How do you convince stakeholders that it's worth it if you only have an idea so far? Consider showing them a prototype or a clear concept of your solution. While this might not be the best move for consumer-focused products, it works wonders in B2B and B2B2C setups. In these environments, where feedback cycles can drag on, waiting for weeks just for another demo isn't ideal. A quick, tangible demo can speed up decision-making and keep the collaboration moving smoothly. Here’s How I Approached the Russian Market How it Started As we entered the 2020s, mostly private entities. The proliferation of commercial enterprises was attributed to a reduction in state restrictions on the issuance of permits and regulatory measures on tariff control. This led to a surge in small businesses and intense competition in the market. At that time, my mobility platform operated as a standard taxi service aggregator, competing with other market players like , , and Citymobil for both customers and drivers. The taxi market was facing losses due to escalating competition, while shifts in consumer demand further complicated the landscape. taxi services in Russia were provided by around 4,300 organizations, Uber Yandex Mission aimed to unite all possible transportation players worldwide on a single platform, creating a fundamentally new level of service for corporate clients that prioritizes the speed of car arrival and optimized trip costs. The mobility platform secured the largest driver base in Russia through strategic agreements and partnerships, particularly with Citymobil in 2020 and another major player in 2021. The mobility platform Our product team's objective After these partnership agreements, I had to synchronize numerous processes. One of the key tasks was to optimize the distribution of customer orders on the platform among providers to enhance reliability and reduce costs for each trip. However, a critical market question arose: How do we decide whom to use and the best pathways for the customer? Here are the steps we took: Started with manual rules for distributing orders among providers. Observed the results, but they were not satisfactory. Conceptualized an that could make decisions on the distribution of each specific trip based on its unique criteria: ML model Order profile: location, duration, time, etc. Market metrics of each provider. Real-time data on our partners: dynamic prices, driver locations. Historical market knowledge in each location and an assessment of the current situation at a given time. Two factors to consider: major expenses are unrelated to the trip—acquisition and operational costs. The following data points illustrate how ML-driven decisions surpass manually-made ones Top Metrics: Increased the percentage of successful orders by 1.7% Reduced driver search time by 12% Increased trip revenue by 9% Control - manual driver search configuration Test - using the ML model. GCR – gross completion rate (rides taken out of all booked), higher is better % Cancelled – how many rides get cancelled after a driver is found, lower is better GP per ride – gross profit per ride, higher is better Margin – revenue per ride, less driver/partner payments, higher is better AVG AT – time it takes to find a driver, lower is better Take these recommendations with you to make ML deployment processes more efficient: While optimizing for efficiency and cost-effectiveness is crucial, you should maintain a strong focus on user experience. Balancing the algorithmic decision-making process with user preferences and expectations is essential to ensure sustained customer loyalty. Regular feedback mechanisms and user surveys can provide valuable insights into evolving customer needs. User-focused optimization: Recognizing the differences between markets, especially the on-demand nature of the Russian taxi market, is vital. You should tailor its strategies to suit the specific demands and behaviors of each market it operates in. This may involve adjusting algorithms, promotional strategies, or service offerings to align with the unique characteristics of each region. Market-specific strategies: The success metrics showcased in the case study are positive indicators, but you should establish a continuous evaluation process. Regularly assessing the impact of ML-driven decisions on key performance indicators, market share, and customer satisfaction will allow for prompt adjustments and enhancements. Sustain investment in machine learning technologies across various operational facets, ensuring ongoing refinement and adaptation to market changes. This should extend beyond supply allocation logic to other critical operations. Regular evaluation and adjustment:

Optimizing Ride-Hailing with Machine Learning: A Product Manager's Journey

মেশিন লার্নিং সহ রাইড-হেইলিং অপ্টিমাইজ করা: একটি পণ্য পরিচালকের যাত্রা

Mitfahrdienste mit maschinellem Lernen optimieren: Die Reise eines Produktmanagers

Optimización del transporte compartido con aprendizaje automático: el viaje de un gerente de producto

Optimiser les services de covoiturage avec l'apprentissage automatique : le parcours d'un chef de produit

मशीन लर्निंग के साथ राइड-हेलिंग को अनुकूलित करना: एक उत्पाद प्रबंधक की यात्रा

機械学習による配車サービスの最適化: プロダクトマネージャーの旅

머신 러닝을 통한 차량 공유 최적화: 제품 관리자의 여정

Otimizando Ride-Hailing com aprendizado de máquina: a jornada de um gerente de produto

Оптимизация заказов пассажиров с помощью машинного обучения: путь менеджера по продукту

Araç Aramayı Makine Öğrenimiyle Optimize Etme: Bir Ürün Yöneticisinin Yolculuğu

Tối ưu hóa dịch vụ gọi xe bằng Machine Learning: Hành trình của Giám đốc sản phẩm

利用机器学习优化叫车服务：产品经理的旅程

When using the Angular CDK Overlay module, you will likely want to transition the opening and closing of the overlay content. It’s something that seems like it should be pretty easy and straightforward, but it’s actually a little tricky. It can’t really be transitioned with only because it’s a markup that gets added into and removed from the document. It’s not a simple style or class change. We need to leverage Angular animations to make it work well. In this post I’ll show you why and I’ll show you how to make animations work for your overlays. Alright, let’s get to it! CSS https://youtu.be/JEKQ21mXyA0?embedable=true Ok, before we get too far along, I’ve created several posts on the Angular CDK Overlay module where I demonstrate how to set up overlays for some common scenarios, how they are positioned, and how they react when scrolling the containers they are contained within. Angular CDK Overlay Tutorials: Learn the Basics How Positioning Works Scroll Strategies So, if you’re new to these concepts, you’ll probably want to check them out first because everything we’ll see in this post will build off the concepts from those videos. The Demo Application Ok, here we have the example that we’ve been working on throughout the videos on the Overlay module. It’s a list of NBA players, and when we click the button on the right, we get a pop-up that’s created with the Overlay module with more details about the player. It works well, but we want to ease in the pop-up when it opens, and then we want to ease it out when it closes. This should be easy, right? Using an Angular and Animation to Animate the CDK Overlay :enter :leave If you’ve used Angular animations in the past, you’d probably expect to use a simple and animation. This type of animation in Angular allows us to animate items that are physically entering into and out of the DOM. This is something that CSS currently does not support. :enter :leave So, let’s try this and see what happens. Creating an :enter/:leave Animation in the Component Animations Metadata Let’s start by adding the animations array. Within this array, let’s add a trigger. We’ll call it “animation”. player-details.component.ts @Component({
    selector: 'app-player-details',
    ...
    animations: [
        trigger('animation', [
        ])
    ]
}) Then, let’s add a transition for our event. Well use the method to add the style we’ll start from. We’ll add a style object where we’ll start from an opacity of zero. And, we’ll start from a scale of point eight. Then, we’ll use the method; for the timings, we’ll use a duration of zero point one five seconds, and we’ll use for our timing function. And we’ll animate to another style object. This time, we’ll be transitioning to an opacity of one and a scale of one as well. :enter style() animate() ease-in-out @Component({
    selector: 'app-player-details',
    ...
    animations: [
        transition(':enter', [
            style({
                opacity: 0,
                transform: 'scale(0.8)'
            }),
            animate('0.15s ease-in-out', style({
                opacity: 1,
                transform: 'scale(1)'
            }))
        ])
    ]
}) Now we’ll add another transition for our :leave state. This time we’ll start from our open state with a style object containing an opacity of one and a scale of one too. Then, we’ll add another animation function. We’ll add the same timing, zero point one five seconds with an timing function. We’ll add another style object to animate to an opacity of zero and a scale of zero point eight, so the inverse of our enter animation. ease-in-out @Component({
    selector: 'app-player-details',
    ...
    animations: [
        trigger('animation', [
            transition(':enter', [
                style({
                    opacity: 0,
                    transform: 'scale(0.8)'
                }),
                animate('0.15s ease-in-out', style({
                    opacity: 1,
                    transform: 'scale(1)'
                }))
            ]),
            transition(':leave', [
                style({
                    opacity: 1,
                    transform: 'scale(1)'
                }),
                animate('0.15s ease-in-out', style({
                    opacity: 0,
                    transform: 'scale(0.8)'
                }))
            ])
        ])
    ]
}) Binding the Animation to the Component Host With the Decorator @HostBinding Ok, now we have the animation setup, but we need to bind it to our player details host element. So, we need to add the decorator. We’ll add our animation trigger, then we’ll create an “animationState” property, and we’ll set it to true so that our animation will properly be bound on the host. @HostBinding export class PlayerDetailsComponent {
    @HostBinding('@animation') animationState = true;
} Ok, now let’s check this out and see what happens. Nice, the animation on open looks great but when we close it looks like it didn’t animate. And, this is because a leave event didn’t fire for this inner component that we’re trying to animate. The overlay is destroyed and removed before the close animation can run. The overlay is detached before the animation completes. We need to complete the close animation before the overlay is detached. So, we’re going to need to do this a different way. Using an Angular State-based Animation to Animate the CDK Overlay What we can do here is actually switch to a state-based animation. We’ll go with the concept of having a “hidden” state and a “visible” state for our overlay content. Creating a State-based Animation in the Component Animations Metadata Let’s remove the code for the :enter/:leave animation and then replace it with our hidden state. We’ll add a style object with opacity zero and a scale of zero point eight. @Component({
    selector: 'app-player-details',
    ...
    animations: [
        trigger('animation', [
            state('hidden', style({
                opacity: 0,
                transform: 'scale(0.8)'
            })
        ])
    ]
}) Then, we’ll add another state call for our visible state. This state will have a style object with an opacity of one and a scale of one as well. @Component({
    selector: 'app-player-details',
    ...
    animations: [
        trigger('animation', [
            state('hidden', style({
                opacity: 0,
                transform: 'scale(0.8)'
            }),
            state('visible', style({
                opacity: 1,
                transform: 'scale(1)'
            }))
        ])
    ]
}) Alright, now we just need to add the transition between these states, so let’s add the transition function. And we’ll transition between hidden and visible states. We’ll also animate this transition with the animation function. Our animation will run over zero point one for five seconds and will use an timing function. ease-in-out @Component({
    selector: 'app-player-details',
    ...
    animations: [
        trigger('animation', [
            state('hidden', style({
                opacity: 0,
                transform: 'scale(0.8)'
            }),
            state('visible', style({
                opacity: 1,
                transform: 'scale(1)'
            })),
            transition('hidden <=> visible', animate('0.15s ease-in-out'))
        ])
    ]
}) Ok, now, for this animation to work correctly, we’ll need to switch our from a Boolean to a hidden/visible string instead, so we’ll initialize it to hidden. animationState export class PlayerDetailsComponent {
    @HostBinding('@animation') animationState = 'hidden';
} Triggering the State-based Animation When Opening and Closing the CDK Overlay Now, when the component is created, we’ll set this property to visible, which will then trigger the open animation to run. We need to add the AfterViewInit lifecycle hook for this. And we’ll need to implement the interface too. Then, within the hook, we’ll set our to visible. animationState export class PlayerDetailsComponent implements AfterViewInit {
    ...
    ngAfterViewInit() {
        this.animationState = 'visible';
    }
} That will trigger the animation on open. Now, we need to handle the close. To do this, we need to do a few things. First, let’s add a public close method. Inside of this method, let’s set our animationState to hidden. export class PlayerDetailsComponent implements AfterViewInit {
    ...
    close() {
        this.animationState = 'hidden';
    }
} Ok, now, in our player component that opens this pop-up, we need to be able to access the instance of our player details component so that we can call the close method that we just added. We’ll use the view child decorator to do this. Its selector will be the , and we’ll name this property . It will be typed to the as well. PlayerDetailsComponent detailsComponent PlayerDetailsComponent player.component.ts export class PlayerComponent {
    @ViewChild(PlayerDetailsComponent) detailsComponent!: PlayerDetailsComponent;
} Ok, now, in our component template, in the event, we’ll now call our method instead of setting our property to false. overlayOutsideClick detailsComponent.close() detailsOpen player.component.html <ng-template
    cdkConnectedOverlay
    ...
    (overlayOutsideClick)="detailsComponent.close()">
</ng-template> So, this will trigger the close animation to run, but it will not actually detach the overlay. In order to properly detach the overlay, we need to wait until the close animation completes and then notify the player component so that it can properly detach the overlay. Using the Angular Animation Done Event and an EventEmitter to Close the CDK Overlay So, back over in the player details component, we need to add an that will emit when the animation completes. We can add the output decorator with a closed property. This property will be a void event emitter. We’ll fire it when the close animation completes. @Output player-details.component.ts export class PlayerDetailsComponent implements AfterViewInit {
    ...
    @Output() closed = new EventEmitter<void>();
} Now, we need a way to wire up to the close animation done event. To do this, we’ll use an animation-done event callback. Since our animation is bound to the host of this component, we’ll need to use the decorator to listen for the animation done event. And we’ll need to pass through the event. Then, we’ll create a done method. And it will have an event parameter that will be typed to an event. Within this method, we need to check if we are animating to the hidden state. Then, within this check, we’ll emit our closed event. @HostListener AngularAnimation export class PlayerDetailsComponent implements AfterViewInit {
    ...
    @HostListener('@animation.done', ['$event']) done(event: AnimationEvent) {
        if (event.toState === 'hidden') {
            this.closed.emit();
        }
    }
} The last thing we need to do is detach the overlay when this event fires. So, let’s go back to the player component template. On our player details component, let’s add our closed event. When it fires, we’ll set the property to false. detailsOpen <ng-template
    cdkConnectedOverlay
    ...>
    <app-player-details [player]="player" (closed)="detailsOpen = false"></app-player-details>
</ng-template> Ok, now it will still transition as it opens and it will now transition when when it closes too. Cool, so now we have a working open and close animation for our pop-ups, but we can make it even better. Making the Animation Better With the @Input cdkConnectedOverlayTransformOriginOn The directive provides the ability for us to specify the item to place a on in order to better animate the overlay from the origin element. To do this, we can add the and in this case, we are animating the element, so we’ll set that as the selector for this input. cdkConnectedOverlay transform-origin cdkConnectedOverlayTransformOriginOn @Input app-player-details <ng-template
    cdkConnectedOverlay
    ...
    cdkConnectedOverlayTransformOriginOn="app-player-details">
</ng-template> Nice, now our pop-up will animate from and to the attachment point on the origin. Ok, so now you know how to animate the opening and closing of overlays. I hope this helps you as you build out modals, pop-ups, tool tips and similar items in your angular apps. Keep an eye out for more videos on the Overlay module in the future. Found This Helpful? If you found this article helpful and want to show some love, you can always buy me a coffee! Want to See It in Action? Check out the demo code and examples of these techniques in the in the stackblitz example below. If you have any questions or thoughts, don’t hesitate to leave a comment. https://stackblitz.com/edit/stackblitz-starters-hi2gdg?ctl=1&embed=1&file=src%2Fplayer%2Fplayer-details%2Fplayer-details.component.ts&embedable=true Also published . here

Animating Angular CDK Overlays

Time is a huge topic. I mean, since the start of the times. Our species has thinking about time since a millennia ago. We don’t know the precise date when that happened because we didn’t take account of time until we ponder a lot about it. So, we could sometimes overlook some nuances of time. And that happened to the team that wrote some tests in a Rails project. Once Upon a Time, There Was a Ruby Project Dealing With Time… I started collaborating on that project where I took a tech-lead role. I was performing more code reviews than coding. And one of the first things that popped up to my eye when reviewing pull requests was that the team was changing tests even when the change was a refactor. “Why are you rewriting tests for a refactor? In a refactor, tests should remain the same. That tells us that the refactored code is working in the same way as the older code! ” I added in my comments. The frustrated team members pointed out that each week, at least one test fails because it depends on the date. One app controller retrieves the results of people whose birthday occurs on that week. If they run the test suite in a different week, they need to update the expected result. I was shocked! I was planning to add a task for refactoring those tests until the product owner said, “No! On this point, we need to create stories that add value to the final user. Tests are important, but they don’t add value to the final user!” I didn’t want to argue, so I accepted the ridiculous reality with stoicism. I continued performing code reviews, and I learned to ignore changes on tests. But after a while, I found the time to tackle those disgraceful test cases. And I found the gem «timecop», a gem created by and maintained by John Trupiano Travis Jeffery. What Does Timecop Do? Timecop is a ruby gem created for those specific cases where we have tests dependent on time. It could be birthdays, but also it could be expiration days for JWT tokens or recurrent billings. In a single line, Timecop creates a mock of Time.now, Date.today, and DateTime.now. As Timecop creators highlight in their README file, the gem doesn’t have dependencies, so it works well with any Ruby test framework. With only two basic methods ( and ), you can easily control the time! Time.travel Time.freeze How to Install Timecop Timecop is a ruby gem available on rubygems.org. So, you can just add Timecop to your Gemfile and run after that. Unless you're using Timecop for something different to testing, add the gem in a test group. bundle install Gemfile ...
group :test do
  ... # Other gems
  gem 'timecop'
end Alternatively, run or install it on your computer with . bundle add timecop gem install timecop To Timecop.travel or To Timecop.freeze? As I commented above, you only need to know two methods for using Timecop: Timecop.travel and Timecop.freeze. But what is the difference between these two methods? Timecop.travel Method With , you set up time to a specific date, and then time will move forward after that. Timecop.travel For example, if you to February 2, 1993, 6:00:00 AM, after ten seconds, returns February 2, 1993, 6:00:10 AM Timecop.travel Time.now groundhog_day = Time.local(1993, 2, 2, 6, 0, 0)
Timecop.travel(groundhog_day)
sleep(10)
groundhog_day == Time.now # ==> false Timecop.freeze Method On the other way, with time stops completely. So, using a similar example, will return exactly on February 2, 1993, 6:00:00 AM: Timecop.freeze Time.now groundhog_day = Time.local(1993, 2, 2, 6, 0, 0)
Timecop.travel(groundhog_day)
sleep(10)
groundhog_day == Time.now # ==> true Other Useful Methods Other Timecop methods allow you to move time faster or return to the system date. Timecop.scale Move times faster. It’s a good option for integration tests where you want to check that some jobs are performed. Code example: # seconds will now seem like hours
Timecop.scale(3600)
Time.now
# => 2012-09-20 21:23:25 -0500
# seconds later, hours have passed and it's gone from 9pm at night to 6am in the morning
Time.now
# => 2012-09-21 06:22:59 -0500 Timecop.return Move time to system date again. GROUNDHOG_DAY = Time.local(1993, 2, 2, 23, 59, 51)

def groundhog_day? = Time.now == GROUNDHOG_DAY

Timecop.freeze(GROUNDHOG_DAY)
sleep(10)

groundhog_day? # => True

Timecop.return

groundhog_day? #=> False Set the Time of Your Tests’ Cases Timecop readme is really clear for its usage. For using Timecop in a time-sensitive test: joe = User.find(1)
joe.purchase_home()
assert !joe.mortgage_due?
# move ahead a month and assert that the mortgage is due
Timecop.freeze(Date.today + 30) do
  assert joe.mortgage_due?
end For use in a group of tests, you write: describe "some set of tests to mock" do
  before do
    Timecop.freeze(Time.local(1990))
  end

  after do
    Timecop.return
  end

  it "should do blah blah blah" do
  end
end Set the Start Time of Your Test Environment for Your Rails Project If you want to set up your test environment to always start on the same date, add this configuration: config/environment/ test.rb ... # your configuration
  config.after_initialize do
    # Set Time.now to February 2, 1993 06:00:00 AM (at this instant), but allow it to move forward
    # year, month, day, hour, min, sec
    t = Time.local(1993, 2, 2, 6, 0, 0)
    Timecop.travel(t)
  end
...
end After that, each time that you run your test, the date will start on February 2 at 6:00 AM. That’s all! I hope you found Timecop as useful as this post.

Timecop: A Ruby Gem to Write Time-Sensitives Tests

LOS ANGELES, California, January 17th, 2024/Chainwire/ Key Takeaways Focus, the revolutionary new decentralized SocialFi app, raised $20 million in less than 24 hours Focus rivals subscription platforms like OnlyFans and Patreon, a multi-billion-dollar industry The Social Airdrop offers users the chance to earn upwards of $100,000 in $FOCUS tokens is a brand new SocialFi app from DeSo, the team that raised $200M from Coinbase, Sequoia, a16z, Social Capital, and other top funds. It aims to disrupt the trillion-dollar social media market and creator economy by introducing groundbreaking features rivaling X, Onlyfans, and Patreon. Focus The TAM for this market is significant, with OnlyFans processing roughly $8 Billion in 2023 and charging 20% per transaction. These high fees significantly reduce creator profits, highlighting the need for a more equitable solution. Focus combines the best of Onlyfans, Patreon, X, and other billion-dollar social platforms into one app. It's built on the and powered by permissionless crypto-native monetization features that are not possible in web2. DeSo blockchain Under the leadership of crypto-veteran , Focus is fully decentralized, with no corporate entity behind it. Just coins and code: Nader Al-Naji “Decentralized social media is facing the same skepticism Bitcoin did at its inception. Critics believe it can't challenge major players, won't scale, and faces a ban if it does. Ask yourself: do you want to be on the side that's short-sighted and left behind or embrace optimism and innovation? This is your chance to be part of a monumental technological shift.” – , Founder of DeSo. Nader Al-Naji allows new ways for users to make money with anonymous crypto-enabled monetization mechanics that include paid reposts (decentralized ads), paid messages, unlockable content, subscriptions, and Creator Coins, allowing users to invest directly in other creators’ revenue streams. Focus Thanks to the DeSo blockchain and its system, Focus users can transact in a variety of cryptocurrencies, including USDC, Bitcoin, Ethereum, Solana, DeSo, and Focus tokens, all for under 1/10,000th of a cent per transaction, including for cross-chain assets. Revolution Proof of Stake DeSo also supports the storage of content directly on-chain for 1/10,000th of a cent per post, which is much less than Solana at ~$1 per post or Ethereum at ~$100+ per post. This means that Focus can pioneer innovative monetization and content mechanics that are not possible with older high-fee blockchains or slower and heavily censored fiat payment rails. DeSo Founder Nader Al-Naji continues: "From the beginning, our strategy was clear: lay down a scalable, decentralized groundwork, then roll out applications that truly showcase the unparalleled advantages and power of DeSo." Focus allows users to reserve tokens akin to staking, with the flexibility to choose any supported currency via , including BTC, ETH, SOL, USDC, and DESO. Early adopters who reserve tokens during the first week (January 11th to January 18th) will receive a 100% bonus in $FOCUS tokens. HeroSwap Unlike traditional social networks, Focus democratizes distribution by distributing 100% of all fees directly to the holders of $FOCUS tokens. This contradicts the business model users see with social platforms today, where a small group of venture capitalists and shareholders capture all the value. To further incentivize user participation, Focus is introducing a viral airdrop model, The Social Airdrop, which rewards users based on their influence on external social networks, distributing $FOCUS tokens commensurate with their reach. This new airdrop model means someone with a thousand views per post would get a joining bonus of about $100 in $FOCUS tokens. In contrast, someone with millions of views per post, like Elon Musk, would get a bonus of upwards of $100,000 in $FOCUS tokens. The Social Airdrop also includes a referral program allowing users to refer others to the platform and in return receive 10% of the referee's joining bonus and 5% of all revenues the referee generates on the platform. FOCUS plans to support X, Instagram, YouTube, TikTok, Twitch, select email domains, DeSo, and OnlyFans at launch. To reserve tokens and earn a 100% bonus in $FOCUS, prospective users should visit and reserve their funds before 11:11 am EST on January 18th. The bonus will drop every week until the app goes live. Focus.xyz About Deso is the first and only censorship-resistant Layer-1 blockchain purpose-built to power storage-heavy apps and scale decentralized social networks for mass adoption. Their mission is to decentralize social media like Bitcoin and Ethereum are decentralizing finance. DeSo has gained significant adoption and boasts (wallets) and 93M transactions. With , DeSo aims to usher in a new age in crypto led by cutting-edge consumer apps that scale to billions of users. DeSo 2.6M users Focus Contact Ed Moss Ed@deso.org This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here.

DeSo-Backed SocialFi App Focus Raises $20 Million In Under 24 Hours

As a startup founder in the sports industry, you may have heard about the potential of AI in fitness software over the past decade. However, incorporating into your fitness applications can still be confusing, especially if you haven’t worked with AI before. Today, we'd like to summarize what AI technology can offer to fitness applications and illustrate its use with some real-world examples. AI Virtual Coaching Applications AI coaching apps analyze exercise recordings in real-time, using computer vision and motion analysis. Users record their exercises with smartphones or wearables, capturing video or motion data. AI algorithms extract key points and track movements to assess form and biomechanics. By comparing to ideal standards, based on expert input or datasets, the app provides personalized, real-time feedback. This benefits users without access to in-person trainers, improving exercise technique and guidance. , a sports technology startup, is an example of an application that offers advanced specialized training for athletes. One of their innovative features is "comparative training," which allows athletes to compare their body mechanics and positioning with a proxy for perfect training. By using this app, athletes can learn and enhance their technique for better performance. BeONE Sports https://youtu.be/NbOgvXVYlH0?si=BAC4qL3UoC3ApsCH&embedable=true Personalized Workout Recommendations AI-powered personalized workout recommendation apps can generate customized workout plans. Users provide information about their fitness goals, exercise history, preferences, and limitations. This data forms a user profile that guides the AI algorithm. The algorithm then analyzes user data and identifies correlations between exercises, workout durations, intensity levels, and outcomes. This personalized approach increases user engagement, motivation, and the likelihood of achieving desired fitness outcomes. You can find many examples of AI-based personal training apps on the market like , Fitbod, Freeletics, Zing Coach, and more. Evolve AI Rehabilitation Solutions AI can be utilized in the rehabilitation and recovery process for individuals with injuries, disabilities, or those undergoing medical treatments. These apps provide personalized guidance, monitoring, and support to help users enhance their physical function and regain mobility. They often incorporate wearable devices or sensors to track movements and relevant metrics during exercises. AI algorithms analyze the collected data to monitor progress and offer performance feedback in real-time. It's still crucial to remember that these apps are intended to complement and enhance the rehabilitation process under the supervision of healthcare professionals rather than replacing professional medical advice and supervision. Our team at MobiDev has been developing an application for the rehabilitation and remote care of the elderly. This app incorporates a to detect and analyze pose movements. By comparing the user's exercise performance with a "virtual trainer," the app offers personalized recommendations on technique and injury prevention. human pose estimation model All-In-One Coaching Bots Coaching bots are examples of solutions that integrate various AI technologies, including human pose estimation and conversational AI. They can assist athletes in refining their exercise technique, correcting posture, selecting appropriate exercises, offering diet recommendations, and more. These comprehensive coaching bots leverage AI to provide the latest advancements in fitness technology, delivering a convenient, all-in-one app experience. Challenges and Future of Adopting AI in Fitness Despite all the exciting things that AI can bring to , the incorporation of this technology has certain challenges that you should be prepared for. building software products AI apps heavily rely on user-provided data, which can be challenging to input accurately. Motion analytics, for example, require users to follow strict filming rules to capture usable video. Poor lighting, inappropriate angles, and occlusive objects can result in frustrating retakes and inadequate input for the AI models. Technical Limitations: Fitness AI apps require a vast amount of data to recognize various body dimensions, sleeping patterns, and training capabilities. Collecting this data is an ongoing process, limiting the full potential of AI-enabled fitness apps until sufficient data is available. Data Accessibility: The lack of transparency in AI decision-making raises concerns about trusting AI coaching recommendations. Users may question the ethics and reasoning behind AI's suggestions. Developers face the challenge of making applications more trustworthy by providing explanations behind AI decisions. Trustworthiness of AI: : AI-enabled fitness apps that collect and store information about diet programming or rehabilitation procedures must navigate healthcare regulations and privacy concerns. The broader the scope of the AI fitness project, the more privacy considerations it encompasses. Privacy and Regulations At the same time, the rapid advancement of artificial intelligence presents significant opportunities for founders of fitness and sports startups. To capitalize on this trend, it’s a good idea to begin integrating smart functionality into your offerings now. By doing so, you can establish a strong foundation for growth in this emerging and progressive market.

How AI Transforms the Fitness Industry

কীভাবে এআই ফিটনেস শিল্পকে রূপান্তরিত করে

Wie KI die Fitnessbranche verändert

Cómo la IA transforma la industria del fitness

Comment l'IA transforme l'industrie du fitness

एआई फिटनेस उद्योग को कैसे बदल देता है

AI がフィットネス業界をどのように変革するか

AI가 피트니스 산업을 변화시키는 방법

Como a IA transforma a indústria do fitness

Как искусственный интеллект меняет фитнес-индустрию

Yapay Zeka Fitness Sektörünü Nasıl Dönüştürüyor?

AI biến đổi ngành thể hình như thế nào

人工智能如何改变健身行业

ONEAPP

oneapp.ly

-- employees

Since n.d.

COMPANY RANKING

ONEAPP

EVERGREEN INDEX #7483

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

OneApp WIKI

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

ONEAPP

oneapp.ly

-- employees

Since n.d.

COMPANY RANKING

ONEAPP

EVERGREEN INDEX #7483

RELATED COMPANIESRANK

STORIES ABOUT ONEAPP

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

OneApp WIKI

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