VRTogether

vrtogether

Virtual reality (VR) may soon replace pictures as the standard visualization tool for online property listings. How will this technology impact buyers and sellers while reshaping the real estate market? The Emerging Trend of VR Home Tours in Real Estate VR technology enables you to tour every room in a property and speak face-to-face with the rental agent without leaving the comfort of your living room couch. This might be why its global market value in the real estate sector will increase to $2.6 billion in 2025, up from $800 million in 2020. One of the biggest advantages of virtual home tours is accessibility. It doesn’t matter if a property is under construction or occupied by the owners — with VR, you can walk through it anyway. You can even schedule an assisted walkthrough with a rental or listing agent to get insider information on the property, even if you’re both on opposite ends of the country. If you plan on moving into a fixer-upper, you can use VR technology to visualize the property’s potential by overlaying renovations or design changes onto the real-world model. These features make this type of tour one of the most personal and immersive — which is why it’s catching on so quickly. With interest rates rising — the interest rate on 30-year mortgages increased from an average of 3.02% in 2020 to 5.8%-6.1% in 2024 — real estate demand is slowing. This is where VR comes in. It has the unique opportunity to benefit buyers and sellers by making touring more efficient and getting properties off the market faster. The Technical Advancements Making It All Possible While VR technology is fundamental to a virtual home tour, a handful of other innovations make it possible. The first is high-resolution 3D imaging, where a 360-degree camera scans the property. The seller then stitches the images together with specialized software to make a realistic virtual replica for tours. The second innovation making VR home tours possible is the Internet of Things (IoT). Sellers can use interconnected sensors to feed real-time data into the virtual world to make it more dynamic. Alternatively, they can use internet-connected edge devices to reduce the computational and bandwidth-related strain on end users. Advances in controllers and motion sensors have made interactivity possible. Instead of sitting through a prerecorded guided tour, you can move through the property at your own pace. Also, you can trigger animations — like lowering the blinds or opening the cabinets — with a flick of your wrist. Considering consumer applications makeup 53% of the VR market, the number of technological advancements directed toward real estate shouldn’t surprise you. There’s a lot of money in researching and developing software, design, and hosting platforms for these applications. The Implications of VR-Driven Real Estate Showings VR technology makes home tours more accessible, broadening the pool of interested parties. According to experts, they reach more potential buyers than the standard approach. They don’t just attract more people — they’re also more engaging. Usually, you only can see a property’s layout when looking at its listing online. If you’re lucky, you’ll also get many high-quality pictures. However, even those don’t give you a good idea of how it feels to be in the house. VR engages you more because it places you in an immersive, lifelike replica where you have agency and control. While the buyer-side implications of virtual home tours might be more noticeable, the seller-side ones are more impactful. Properties using VR real estate showings have selling prices 7.25% higher than the benchmark. Heightened buyer engagement and broadened accessibility lead to a competitive advantage. The process moves more quickly since virtual tours don’t require in-person assistance or scheduling. Some experts claim properties using VR real estate showings spend 20%-30% fewer days on the market. As a result, agents can take on more listings at once. Potential Challenges Buyers and Sellers Face Using VR Although VR home tours benefit buyers and sellers, they also often come with challenges — with the lack of VR headset accessibility being one of the most significant. While virtual viewings are still possible without one, immersive experiences are only possible with mid- or high-end equipment. Properties in low-income locations are more likely to be impacted by this issue. Another challenge buyers and sellers face is agent accessibility. While virtual home tours don’t need an assistant, many serious buyers want one so they can ask questions. However, the increased attention VR listings get can complicate scheduling. The last potential challenge revolves around the accuracy of virtual property replicas. Even though developing one costs less than $300 on average, some sellers might be unable to afford to redo theirs every time they renovate or change something. As a result, the tour might not resemble its real-life counterpart — making buyers feel misled. The Future Outlook of VR Home Tours in Real Estate Sellers can use VR to track eye movement, location data, and interaction information to see where buyers come from and which properties they’re most interested in. This way, they can optimize their marketing, demand forecasting, pricing, and risk assessment strategies. At the same time, buyers can remotely walk through properties regardless of location and conditions. VR technology’s impact on accessibility and engagement will likely transform what the standard property sale looks like. VR technology has the potential to permanently transform the real estate market, becoming the go-to choice for sellers and prospective buyers. As its popularity increases, it might become standard to include it alongside layout and property pictures and come to be something people expect to see. Virtual reality (VR) may soon replace pictures as the standard visualization tool for online property listings. How will this technology impact buyers and sellers while reshaping the real estate market? The Emerging Trend of VR Home Tours in Real Estate The Emerging Trend of VR Home Tours in Real Estate VR technology enables you to tour every room in a property and speak face-to-face with the rental agent without leaving the comfort of your living room couch. This might be why its global market value in the real estate sector will increase to $2.6 billion in 2025, up from $800 million in 2020. will increase to $2.6 billion will increase to $2.6 billion One of the biggest advantages of virtual home tours is accessibility. It doesn’t matter if a property is under construction or occupied by the owners — with VR, you can walk through it anyway. You can even schedule an assisted walkthrough with a rental or listing agent to get insider information on the property, even if you’re both on opposite ends of the country. If you plan on moving into a fixer-upper, you can use VR technology to visualize the property’s potential by overlaying renovations or design changes onto the real-world model. These features make this type of tour one of the most personal and immersive — which is why it’s catching on so quickly. With interest rates rising — the interest rate on 30-year mortgages increased from an average of 3.02% in 2020 to 5.8%-6.1% in 2024 — real estate demand is slowing. This is where VR comes in. It has the unique opportunity to benefit buyers and sellers by making touring more efficient and getting properties off the market faster. increased from an average of 3.02% increased from an average of 3.02% The Technical Advancements Making It All Possible While VR technology is fundamental to a virtual home tour, a handful of other innovations make it possible. The first is high-resolution 3D imaging, where a 360-degree camera scans the property. The seller then stitches the images together with specialized software to make a realistic virtual replica for tours. The second innovation making VR home tours possible is the Internet of Things (IoT). Sellers can use interconnected sensors to feed real-time data into the virtual world to make it more dynamic. Alternatively, they can use internet-connected edge devices to reduce the computational and bandwidth-related strain on end users. Advances in controllers and motion sensors have made interactivity possible. Instead of sitting through a prerecorded guided tour, you can move through the property at your own pace. Also, you can trigger animations — like lowering the blinds or opening the cabinets — with a flick of your wrist. Considering consumer applications makeup 53% of the VR market , the number of technological advancements directed toward real estate shouldn’t surprise you. There’s a lot of money in researching and developing software, design, and hosting platforms for these applications. makeup 53% of the VR market makeup 53% of the VR market The Implications of VR-Driven Real Estate Showings VR technology makes home tours more accessible, broadening the pool of interested parties. According to experts, they reach more potential buyers than the standard approach. They don’t just attract more people — they’re also more engaging. reach more potential buyers reach more potential buyers Usually, you only can see a property’s layout when looking at its listing online. If you’re lucky, you’ll also get many high-quality pictures. However, even those don’t give you a good idea of how it feels to be in the house. VR engages you more because it places you in an immersive, lifelike replica where you have agency and control. While the buyer-side implications of virtual home tours might be more noticeable, the seller-side ones are more impactful. Properties using VR real estate showings have selling prices 7.25% higher than the benchmark. Heightened buyer engagement and broadened accessibility lead to a competitive advantage. have selling prices 7.25% higher have selling prices 7.25% higher The process moves more quickly since virtual tours don’t require in-person assistance or scheduling. Some experts claim properties using VR real estate showings spend 20%-30% fewer days on the market. As a result, agents can take on more listings at once. spend 20%-30% fewer days spend 20%-30% fewer days Potential Challenges Buyers and Sellers Face Using VR Although VR home tours benefit buyers and sellers, they also often come with challenges — with the lack of VR headset accessibility being one of the most significant. While virtual viewings are still possible without one, immersive experiences are only possible with mid- or high-end equipment. Properties in low-income locations are more likely to be impacted by this issue. Another challenge buyers and sellers face is agent accessibility. While virtual home tours don’t need an assistant, many serious buyers want one so they can ask questions. However, the increased attention VR listings get can complicate scheduling. The last potential challenge revolves around the accuracy of virtual property replicas. Even though developing one costs less than $300 on average, some sellers might be unable to afford to redo theirs every time they renovate or change something. As a result, the tour might not resemble its real-life counterpart — making buyers feel misled. costs less than $300 costs less than $300 The Future Outlook of VR Home Tours in Real Estate Sellers can use VR to track eye movement, location data, and interaction information to see where buyers come from and which properties they’re most interested in. This way, they can optimize their marketing, demand forecasting, pricing, and risk assessment strategies. At the same time, buyers can remotely walk through properties regardless of location and conditions. VR technology’s impact on accessibility and engagement will likely transform what the standard property sale looks like. VR technology has the potential to permanently transform the real estate market, becoming the go-to choice for sellers and prospective buyers. As its popularity increases, it might become standard to include it alongside layout and property pictures and come to be something people expect to see.

VR Home Tours: The Future of Real Estate Showings

Once, I had a back-and-forth discussion with a coworker about the correct way to use @Component and @StepScope annotations in a Spring-based Java application. We debated whether using both annotations was necessary or if it led to redundancy or unexpected behavior. In this article, I'll share insights from that discussion, clarify the topic, share examples, and provide references to Spring documentation to help guide you through the correct approach. Problem Statement Consider the following scenario: you have a class that requires both Spring's @Component annotation and @StepScope from Spring Batch. The @Component annotation registers your class as a Spring-managed bean, while @StepScope ensures that the bean is instantiated with a lifecycle tied to a specific step in your batch job. The combination may look like this: @Component
@StepScope
public class MyStepScopedComponent {
    // Class implementation
} The question is: Is using @Component with @StepScope redundant or problematic? Does it make sense to use both annotations, or should you use a different approach? Understanding the Annotations @Component: This annotation is part of the core Spring framework. It marks a class as a Spring-managed bean, which means it will be automatically discovered and registered in the Spring application context through component scanning. Typically, @Component beans are singleton-scoped by default, meaning they are created once and used throughout the application's lifecycle.
@StepScope: This is a Spring Batch annotation that specifies the bean should have a scope that is tied to the lifecycle of a batch step. Unlike a singleton bean, a step-scoped bean is instantiated each time a step is executed. This allows it to access resources like job parameters and step-specific data. Is the Combination Acceptable? Yes, using @Component and @StepScope together is acceptable, but there are some important considerations: Bean Lifecycle and Proxy Creation: The @StepScope annotation changes the lifecycle of the bean from the default singleton to one that is created specifically for each step execution. When @StepScope is used, Spring creates a proxy for the bean, meaning that the actual bean instance is created when the step starts, not at application startup.
Avoid Lifecycle Conflicts: Using @Component implies that the bean is part of component scanning and might be treated as a singleton by default. @StepScope changes that lifecycle to step scope. This duality can sometimes create confusion or unexpected behavior if not properly handled. To avoid these issues: Use Lazy Injection: If you inject a step-scoped bean into a singleton-scoped bean, use @Lazy to ensure that the bean is not prematurely instantiated, which can cause problems.
@Component
public class MySingletonBean {
    private final MyStepScopedComponent myStepScopedComponent;

    public MySingletonBean(@Lazy MyStepScopedComponent myStepScopedComponent) {
        this.myStepScopedComponent = myStepScopedComponent;
    }
}



Consider Refactoring to @Bean and @StepScope: If your step-scoped bean requires constructor injection or complex configuration, you might be better off defining it in a configuration class using @Bean.
@Configuration
public class BatchConfiguration {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedComponent() {
        return new MyStepScopedComponent();
    }
} Best Practices Use @StepScope on the Bean Definition Only: When defining your step-scoped bean using @Bean in a @Configuration class, it gives you more control over initialization and prevents scope conflicts.
Avoid Direct Field Injection: Prefer constructor injection with @Lazy to ensure proper lifecycle handling.
Test Thoroughly: Scoping issues often arise from improper initialization timing. Ensure you test thoroughly to confirm that your job parameters are correctly injected when the step starts. Example with Proper Scope Management Here is an example where a bean is scoped to a batch step but defined in a configuration class for better clarity and control: @Configuration
public class BatchJobConfig {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedBean(@Value("#{jobParameters['inputFileName']}") String inputFileName) {
        return new MyStepScopedComponent(inputFileName);
    }
} In this example, the @StepScope ensures that a new instance of MyStepScopedComponent is created for each step execution, and the inputFileName job parameter is injected correctly. References and Resources To better understand the nuances of using @StepScope and its interaction with other Spring annotations, I recommend checking the following references: Spring Batch Step Scope Documentation provides details about the usage and lifecycle of @StepScope.
Delft Stack's Guide on Step Scope in Spring Batch offers a practical explanation of how to configure step-scoped beans, including examples in XML and Java configurations. Conclusion Using @Component and @StepScope together is technically allowed, but understanding their differences and potential conflicts is key to using them effectively. If you're unsure, consider defining your step-scoped beans in a @Configuration class with @Bean and @StepScope for better lifecycle management and clarity. For any questions or further discussion, feel free to comment below or refer to the linked documentation. Once, I had a back-and-forth discussion with a coworker about the correct way to use @Component and @StepScope annotations in a Spring-based Java application. We debated whether using both annotations was necessary or if it led to redundancy or unexpected behavior. In this article, I'll share insights from that discussion, clarify the topic, share examples, and provide references to Spring documentation to help guide you through the correct approach. @Component @StepScope Problem Statement Consider the following scenario: you have a class that requires both Spring's @Component annotation and @StepScope from Spring Batch. The @Component annotation registers your class as a Spring-managed bean, while @StepScope ensures that the bean is instantiated with a lifecycle tied to a specific step in your batch job. The combination may look like this: @Component @StepScope @Component @StepScope @Component
@StepScope
public class MyStepScopedComponent {
    // Class implementation
} @Component
@StepScope
public class MyStepScopedComponent {
    // Class implementation
} The question is: Is using @Component with @StepScope redundant or problematic? Does it make sense to use both annotations, or should you use a different approach? Is using @Component with @StepScope redundant or problematic? Understanding the Annotations @Component: This annotation is part of the core Spring framework. It marks a class as a Spring-managed bean, which means it will be automatically discovered and registered in the Spring application context through component scanning. Typically, @Component beans are singleton-scoped by default, meaning they are created once and used throughout the application's lifecycle. @StepScope: This is a Spring Batch annotation that specifies the bean should have a scope that is tied to the lifecycle of a batch step. Unlike a singleton bean, a step-scoped bean is instantiated each time a step is executed. This allows it to access resources like job parameters and step-specific data. @Component : This annotation is part of the core Spring framework. It marks a class as a Spring-managed bean, which means it will be automatically discovered and registered in the Spring application context through component scanning. Typically, @Component beans are singleton-scoped by default, meaning they are created once and used throughout the application's lifecycle. @Component @Component singleton-scoped @StepScope : This is a Spring Batch annotation that specifies the bean should have a scope that is tied to the lifecycle of a batch step. Unlike a singleton bean, a step-scoped bean is instantiated each time a step is executed . This allows it to access resources like job parameters and step-specific data. @StepScope instantiated each time a step is executed Is the Combination Acceptable? Yes , using @Component and @StepScope together is acceptable, but there are some important considerations: Yes @Component @StepScope Bean Lifecycle and Proxy Creation: The @StepScope annotation changes the lifecycle of the bean from the default singleton to one that is created specifically for each step execution. When @StepScope is used, Spring creates a proxy for the bean, meaning that the actual bean instance is created when the step starts, not at application startup. Avoid Lifecycle Conflicts: Using @Component implies that the bean is part of component scanning and might be treated as a singleton by default. @StepScope changes that lifecycle to step scope. This duality can sometimes create confusion or unexpected behavior if not properly handled. Bean Lifecycle and Proxy Creation : The @StepScope annotation changes the lifecycle of the bean from the default singleton to one that is created specifically for each step execution. When @StepScope is used, Spring creates a proxy for the bean, meaning that the actual bean instance is created when the step starts, not at application startup. Bean Lifecycle and Proxy Creation @StepScope @StepScope Avoid Lifecycle Conflicts : Using @Component implies that the bean is part of component scanning and might be treated as a singleton by default. @StepScope changes that lifecycle to step scope. This duality can sometimes create confusion or unexpected behavior if not properly handled. Avoid Lifecycle Conflicts @Component @StepScope To avoid these issues : To avoid these issues Use Lazy Injection: If you inject a step-scoped bean into a singleton-scoped bean, use @Lazy to ensure that the bean is not prematurely instantiated, which can cause problems.
@Component
public class MySingletonBean {
    private final MyStepScopedComponent myStepScopedComponent;

    public MySingletonBean(@Lazy MyStepScopedComponent myStepScopedComponent) {
        this.myStepScopedComponent = myStepScopedComponent;
    }
} Consider Refactoring to @Bean and @StepScope: If your step-scoped bean requires constructor injection or complex configuration, you might be better off defining it in a configuration class using @Bean.
@Configuration
public class BatchConfiguration {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedComponent() {
        return new MyStepScopedComponent();
    }
} Use Lazy Injection: If you inject a step-scoped bean into a singleton-scoped bean, use @Lazy to ensure that the bean is not prematurely instantiated, which can cause problems. @Component
public class MySingletonBean {
    private final MyStepScopedComponent myStepScopedComponent;

    public MySingletonBean(@Lazy MyStepScopedComponent myStepScopedComponent) {
        this.myStepScopedComponent = myStepScopedComponent;
    }
} Use Lazy Injection : If you inject a step-scoped bean into a singleton-scoped bean, use @Lazy to ensure that the bean is not prematurely instantiated, which can cause problems. Use Lazy Injection @Lazy @Component
public class MySingletonBean {
    private final MyStepScopedComponent myStepScopedComponent;

    public MySingletonBean(@Lazy MyStepScopedComponent myStepScopedComponent) {
        this.myStepScopedComponent = myStepScopedComponent;
    }
} @Component
public class MySingletonBean {
    private final MyStepScopedComponent myStepScopedComponent;

    public MySingletonBean(@Lazy MyStepScopedComponent myStepScopedComponent) {
        this.myStepScopedComponent = myStepScopedComponent;
    }
} Consider Refactoring to @Bean and @StepScope: If your step-scoped bean requires constructor injection or complex configuration, you might be better off defining it in a configuration class using @Bean. @Configuration
public class BatchConfiguration {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedComponent() {
        return new MyStepScopedComponent();
    }
} Consider Refactoring to @Bean and @StepScope : If your step-scoped bean requires constructor injection or complex configuration, you might be better off defining it in a configuration class using @Bean . Consider Refactoring to @Bean and @StepScope @Bean @Configuration
public class BatchConfiguration {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedComponent() {
        return new MyStepScopedComponent();
    }
} @Configuration
public class BatchConfiguration {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedComponent() {
        return new MyStepScopedComponent();
    }
} Best Practices Use @StepScope on the Bean Definition Only: When defining your step-scoped bean using @Bean in a @Configuration class, it gives you more control over initialization and prevents scope conflicts. Avoid Direct Field Injection: Prefer constructor injection with @Lazy to ensure proper lifecycle handling. Test Thoroughly: Scoping issues often arise from improper initialization timing. Ensure you test thoroughly to confirm that your job parameters are correctly injected when the step starts. Use @StepScope on the Bean Definition Only : When defining your step-scoped bean using @Bean in a @Configuration class, it gives you more control over initialization and prevents scope conflicts. Use @StepScope on the Bean Definition Only @Bean @Configuration more control over initialization Avoid Direct Field Injection : Prefer constructor injection with @Lazy to ensure proper lifecycle handling. Avoid Direct Field Injection @Lazy Test Thoroughly : Scoping issues often arise from improper initialization timing. Ensure you test thoroughly to confirm that your job parameters are correctly injected when the step starts. Test Thoroughly Example with Proper Scope Management Here is an example where a bean is scoped to a batch step but defined in a configuration class for better clarity and control: @Configuration
public class BatchJobConfig {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedBean(@Value("#{jobParameters['inputFileName']}") String inputFileName) {
        return new MyStepScopedComponent(inputFileName);
    }
} @Configuration
public class BatchJobConfig {
    @Bean
    @StepScope
    public MyStepScopedComponent myStepScopedBean(@Value("#{jobParameters['inputFileName']}") String inputFileName) {
        return new MyStepScopedComponent(inputFileName);
    }
} In this example, the @StepScope ensures that a new instance of MyStepScopedComponent is created for each step execution, and the inputFileName job parameter is injected correctly. @StepScope MyStepScopedComponent inputFileName References and Resources To better understand the nuances of using @StepScope and its interaction with other Spring annotations, I recommend checking the following references: @StepScope Spring Batch Step Scope Documentation provides details about the usage and lifecycle of @StepScope. Delft Stack's Guide on Step Scope in Spring Batch offers a practical explanation of how to configure step-scoped beans, including examples in XML and Java configurations. Spring Batch Step Scope Documentation provides details about the usage and lifecycle of @StepScope. Spring Batch Step Scope Documentation @StepScope. Delft Stack's Guide on Step Scope in Spring Batch offers a practical explanation of how to configure step-scoped beans, including examples in XML and Java configurations. Delft Stack's Guide on Step Scope in Spring Batch Conclusion Using @Component and @StepScope together is technically allowed, but understanding their differences and potential conflicts is key to using them effectively. If you're unsure, consider defining your step-scoped beans in a @Configuration class with @Bean and @StepScope for better lifecycle management and clarity. @Component @StepScope @Configuration @Bean @StepScope For any questions or further discussion, feel free to comment below or refer to the linked documentation.

Using @Component and @StepScope Together in Java Spring Batch

Table of Links Abstract and 1. Introduction Why ELIZA?
The Intelligence Engineers
Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs
From IPL to SLIP and Lisp
A Critical Tangent into Gomoku
Interpretation is the Core of Intelligence
The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion
Finally ELIZA: A Platform, Not a Chat Bot!
A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community
Another Wave: A BASIC ELIZA turns the PC Generation on to AI
Conclusion: A certain danger lurks there
Acknowledgements and References 8 The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion Interpretation is the process through which a cognitive agent assigns meaning to experience. In the case of ELIZA (or PARRY) “experience” is merely textual interaction with the user. Weizenbaum recognized that ELIZA has no interpretive structures or processes at all. It is, however, worth making a connection between interpretation, and the focus described above on recursion and lists, and language, because this connects all of the threads of research that are described here. To create a completely tied-together coherent explication of this complex knot of concepts would require much more space than is available at the moment, so we will merely touch the topic at a few points which will hopefully be sufficient to give the reader the sense of the whole. First, observe that at the simplest level, a sentence is a “merely” list of words. However, as pointed out by Chomsky, human language is fundamentally recursive, as can easily be seen in either the understanding or production of novel, potentially infinitely deeply nested sentences that may be hard to understand, but which, like this one, are nonetheless grammatical and sensible, for example: “The rat that the cat that the dog chased killed ate the malt.”[20, p. 286] Second, observe that a list (perhaps representing a sentence) is a special case of a graph, and, moreover, a nested list (perhaps representing a nested sentence, like the example above) is just a tree, which is a specific kind of graph. Indeed, Chomsky’s underlying grammars are graphs as well, where elements link to other elements. And even without going into that depth, it is obvious that language is graph-structured, not merely tree-structured even on the surface, through, for example, pronouns which refer to other constituents of the sentences, creating edges in the graph. Third, observe that the belief structures that are used in most AI to represent beliefs are generally graphs, wherein symbols, which might represent concepts, are linked to one another by edges, which might represent relationships between concepts.[8] Fourth, observe that graph (or tree or list) traversal is a naturally recursive process, proceeding from vertex to vertex along the edges of the graph, and that many of the core algorithms of classical “symbolic” AI rely upon various versions of efficient graph (or tree) traversal.[9] Finally (fifth), observe that extended conversations (discourse), is analogous to individual sentences in that at the surface it is linear (list-like), but even going one level down one finds that real discourse contains explicit connections (e.g., “...before you said...”), and, again analogous to our story of interpretation, as well at both the levels of semantic and pragmatic connections that connect parts of the conversation to one another. Given these glosses, it can be seen (roughly) that interpretation is a process – indeed, a computable recursive function, precisely in Turing’s sense – that transforms one sort of graph structure, the surface structure of sentences, and indeed of whole discussions, to another – the meaning – and then back again, into the next turn of the conversation.[10] Although ELIZA only engages in the shallowest such recursive operations in transforming input sentences into output sentences directly in accord with its script, Weizenbaum was explicitly aware that ELIZA’s users – and indeed the users of any AI (or for that matter every human everywhere all the time) – were engaged in interpretation in all is complexity and glory. Putting this more clearly, the users of an AI are interpreting the program as intelligent, and they are led – or perhaps mis-led – to this interpretation by virtue of the program putting forward an appearance of intelligence, or what Weizenbaum called “the illusion of understanding” in his conversation with McCorduck, and, as we shall soon see, in the ELIZA paper itself. It is critical to understand that this “illusion” does not arise through triggering some sort of abnormal cognitive error. Quite to the contrary, it relies – as does all magic – upon the perfectly normal, continuous, and central cognitive process of interpretation that humans are engaged in all the time in everything they do. Without the continuous cognitive process of interpretation, we could not operate, and indeed, we would not be cognitive agents at all. Mistaken interpretation is a common and normal feature of cognition, and is usually easily corrected, if becomes relevant at all.[11] Armed with this insight, we come, finally, to ELIZA itself. Author:
(1) Jeff Shrager, Blue Dot Change and Stanford University Symbolic Systems Program (Adjunct)( jshrager@stanford.edu). This paper is available on arxiv under CC BY 4.0 license. [8] In AIs built out of ANNs the concepts and their inter-relationships are not so concisely represented – usually being diffused across the network, however, the networks themselves are still graphs (indeed, the term “network” is just a synonym for “graph”), and the analytic bases for the construction and analysis of ANNs rest firmly on graph theory. [9] The operation of ANNs relies upon matrix multiplication rather than upon graph traversal, however these are closely related, and, indeed, one commonly implements graph traversal via matrix multiplication. Furthermore, advanced users of ANNs are coming to the realization that in order to understand what the ANN is doing, and to guide it “intelligently” we are likely to end up relying upon more classical sorts of algorithms, resulting in a hybrid of ANN and symbolic AI. [10] NN-based AIs, especially modern Large Language Models (LLMs) usually operate wordby-word (more precisely, token by token), generating the next “most likely” word (token) as result of bubbling the context – i.e., the whole previous interaction (including the LLM’s own outputs) back through the network in what is called a “recurrent” pattern. These are more like ELIZA than they are like the AIs built by Colby, Schank, etc. Instead of an author creating a script, the scripts for LLMs a created by transforming enormous amounts of language, usually scraped from the web, into the incredibly complex graphs describing how words relate to other words in their context, but they have no explicit representation of meaning, aside from the nest of interrelationships burned into and buried in the network. As a result, when engaged in discourse, LLMs act striking like ELIZA in that they can briefly maintain the appearance of understanding but once one attempts to carry on the conversation in a new direction, or refer (directly or indirectly) to previous conversational context, they are essentially as lost as ELIZA, and engage in what might be most charitably described as grammatically correct confabulation. [11] Uncorrected mistaken interpretation maybe be said to be the core problem in some of the cognitive impairments studied by Colby and other psychiatrists. Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Why ELIZA? The Intelligence Engineers Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs From IPL to SLIP and Lisp A Critical Tangent into Gomoku Interpretation is the Core of Intelligence The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion Finally ELIZA: A Platform, Not a Chat Bot! A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community Another Wave: A BASIC ELIZA turns the PC Generation on to AI Conclusion: A certain danger lurks there Acknowledgements and References Why ELIZA? Why ELIZA? The Intelligence Engineers The Intelligence Engineers Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs From IPL to SLIP and Lisp From IPL to SLIP and Lisp A Critical Tangent into Gomoku A Critical Tangent into Gomoku Interpretation is the Core of Intelligence Interpretation is the Core of Intelligence The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion Finally ELIZA: A Platform, Not a Chat Bot! Finally ELIZA: A Platform, Not a Chat Bot! A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community Another Wave: A BASIC ELIZA turns the PC Generation on to AI Another Wave: A BASIC ELIZA turns the PC Generation on to AI Conclusion: A certain danger lurks there Conclusion: A certain danger lurks there Acknowledgements and References Acknowledgements and References 8 The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion Interpretation is the process through which a cognitive agent assigns meaning to experience. In the case of ELIZA (or PARRY) “experience” is merely textual interaction with the user. Weizenbaum recognized that ELIZA has no interpretive structures or processes at all. It is, however, worth making a connection between interpretation, and the focus described above on recursion and lists, and language, because this connects all of the threads of research that are described here. To create a completely tied-together coherent explication of this complex knot of concepts would require much more space than is available at the moment, so we will merely touch the topic at a few points which will hopefully be sufficient to give the reader the sense of the whole. First, observe that at the simplest level, a sentence is a “merely” list of words. However, as pointed out by Chomsky, human language is fundamentally recursive, as can easily be seen in either the understanding or production of novel, potentially infinitely deeply nested sentences that may be hard to understand, but which, like this one, are nonetheless grammatical and sensible, for example: “The rat that the cat that the dog chased killed ate the malt.”[20, p. 286] Second, observe that a list (perhaps representing a sentence) is a special case of a graph, and, moreover, a nested list (perhaps representing a nested sentence, like the example above) is just a tree, which is a specific kind of graph. Indeed, Chomsky’s underlying grammars are graphs as well, where elements link to other elements. And even without going into that depth, it is obvious that language is graph-structured, not merely tree-structured even on the surface, through, for example, pronouns which refer to other constituents of the sentences, creating edges in the graph. Third, observe that the belief structures that are used in most AI to represent beliefs are generally graphs, wherein symbols, which might represent concepts, are linked to one another by edges, which might represent relationships between concepts.[8] Fourth, observe that graph (or tree or list) traversal is a naturally recursive process, proceeding from vertex to vertex along the edges of the graph, and that many of the core algorithms of classical “symbolic” AI rely upon various versions of efficient graph (or tree) traversal.[9] Finally (fifth), observe that extended conversations (discourse), is analogous to individual sentences in that at the surface it is linear (list-like), but even going one level down one finds that real discourse contains explicit connections (e.g., “...before you said...”), and, again analogous to our story of interpretation, as well at both the levels of semantic and pragmatic connections that connect parts of the conversation to one another. Given these glosses, it can be seen (roughly) that interpretation is a process – indeed, a computable recursive function, precisely in Turing’s sense – that transforms one sort of graph structure, the surface structure of sentences, and indeed of whole discussions, to another – the meaning – and then back again, into the next turn of the conversation.[10] Although ELIZA only engages in the shallowest such recursive operations in transforming input sentences into output sentences directly in accord with its script, Weizenbaum was explicitly aware that ELIZA’s users – and indeed the users of any AI (or for that matter every human everywhere all the time) – were engaged in interpretation in all is complexity and glory. Putting this more clearly, the users of an AI are interpreting the program as intelligent, and they are led – or perhaps mis-led – to this interpretation by virtue of the program putting forward an appearance of intelligence, or what Weizenbaum called “the illusion of understanding” in his conversation with McCorduck, and, as we shall soon see, in the ELIZA paper itself. appearance It is critical to understand that this “illusion” does not arise through triggering some sort of abnormal cognitive error. Quite to the contrary, it relies – as does all magic – upon the perfectly normal, continuous, and central cognitive process of interpretation that humans are engaged in all the time in everything they do. Without the continuous cognitive process of interpretation, we could not operate, and indeed, we would not be cognitive agents at all. Mistaken interpretation is a common and normal feature of cognition, and is usually easily corrected, if becomes relevant at all.[11] Armed with this insight, we come, finally, to ELIZA itself. Author: (1) Jeff Shrager, Blue Dot Change and Stanford University Symbolic Systems Program (Adjunct)( jshrager@stanford.edu). Author: Author: (1) Jeff Shrager, Blue Dot Change and Stanford University Symbolic Systems Program (Adjunct)( jshrager@stanford.edu). This paper is available on arxiv under CC BY 4.0 license. This paper is available on arxiv under CC BY 4.0 license. available on arxiv available on arxiv [8] In AIs built out of ANNs the concepts and their inter-relationships are not so concisely represented – usually being diffused across the network, however, the networks themselves are still graphs (indeed, the term “network” is just a synonym for “graph”), and the analytic bases for the construction and analysis of ANNs rest firmly on graph theory. [9] The operation of ANNs relies upon matrix multiplication rather than upon graph traversal, however these are closely related, and, indeed, one commonly implements graph traversal via matrix multiplication. Furthermore, advanced users of ANNs are coming to the realization that in order to understand what the ANN is doing, and to guide it “intelligently” we are likely to end up relying upon more classical sorts of algorithms, resulting in a hybrid of ANN and symbolic AI. [10] NN-based AIs, especially modern Large Language Models (LLMs) usually operate wordby-word (more precisely, token by token), generating the next “most likely” word (token) as result of bubbling the context – i.e., the whole previous interaction (including the LLM’s own outputs) back through the network in what is called a “recurrent” pattern. These are more like ELIZA than they are like the AIs built by Colby, Schank, etc. Instead of an author creating a script, the scripts for LLMs a created by transforming enormous amounts of language, usually scraped from the web, into the incredibly complex graphs describing how words relate to other words in their context, but they have no explicit representation of meaning, aside from the nest of interrelationships burned into and buried in the network. As a result, when engaged in discourse, LLMs act striking like ELIZA in that they can briefly maintain the appearance of understanding but once one attempts to carry on the conversation in a new direction, or refer (directly or indirectly) to previous conversational context, they are essentially as lost as ELIZA, and engage in what might be most charitably described as grammatically correct confabulation. [11] Uncorrected mistaken interpretation maybe be said to be the core problem in some of the cognitive impairments studied by Colby and other psychiatrists.

The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion

Apache Kafka Architecture 101: Internal Components and How They Work Together

**LISBON, Portugal, May 9th, 2024/Chainwire/--**Azuro, the leading liquidity layer for onchain predictions, and Chiliz, the world’s premier sports and entertainment blockchain, are partnering up to accelerate the adoption of onchain sport prediction markets. These efforts will allow millions of fans worldwide to further support and cheer for their favorite teams and athletes through fair and transparent prediction apps. Chiliz Chain is renowned for its blockchain solutions that transform fan engagement in sports through features like fan tokens and interactive engagement platforms. Through its flagship venture Socios.com, the network has expanded significantly to support more than 80 sport-related fan tokens and 2M+ ecosystem users. Team-specific fan tokens for the best football clubs, including FC Barcelona, Inter Milan, Juventus, Paris Saint-Germain, Manchester City, and many more, are all currently supported by Chiliz Chain through Socios. The network leverages a Proof of Staked Authority (PoSA) consensus algorithm which allows smart contract developers, validators, stakers, and other stakeholders to actively interact with the chain. Chiliz Chain is built to power sports and entertainment applications with a focus on brand IP and project use-case integrity. For Chiliz, partnering with Azuro represents a step toward tapping into the rapidly growing onchain prediction markets by the hand of the de facto infrastructure layer for sports prediction applications across EVM chains. Its innovative liquidity pool design, advanced tooling and oracle solutions allow apps to launch without upfront investment or running costs, enabling them to focus entirely on user acquisition, engagement and monetization from minute one. Azuro’s robust platform, currently supports over 25 active applications with transaction volumes surpassing $290 million, offers an ideal environment for Chiliz to expand its offerings in the sports and entertainment sectors. As part of this collaboration, Chiliz will be integrated into the Azuro Protocol, adding to the existing supported chains such as Polygon and Gnosis Chain. This integration will enable Chiliz to expand its reach within sports-focused prediction applications. New and existing builders relying on Azuro infrastructure will be able to connect their apps to the Chiliz Chain and allow their users to place transactions with the blockchain’s native token CHZ. "Integrating with Azuro marks a pivotal move for Chiliz Chain to capitalize on the rapidly expanding onchain prediction market," said Alexandre Dreyfus, CEO of Chiliz and Socios.com. "Leveraging Azuro's advanced infrastructure, we're empowering developers to innovate within the sports and gaming sectors." Rossen, a core contributor at Azuro, stated, “The onchain prediction markets have always been strongly tied to the sports and entertainment sector. Working alongside Chiliz Chain, the leading blockchain in this segment, feels like an obvious step for us. Azuro’s robust infrastructure will help expand Chiliz Chain’s usability within the fast-growing onchain prediction markets.” Looking ahead, Azuro and Chiliz will be soon launching a co-sponsored grants program aimed at incentivizing app developers to build on their combined infrastructure. These initiatives, including bounties for the first apps, are designed to fuel further adoption of onchain prediction markets, and aligned with Azuro’s vision for setting new transparency and fairness standards. About Azuro Azuro is the onchain predictions layer. It consists of modular tooling, oracle and liquidity solutions for EVM chains to host powerful prediction and gaming apps. With its unique infrastructure layer approach Azuro makes on-chain predictions and gaming portable and composable. It allows anyone to engage and monetize users by building apps, integrations, and products quickly, permissionlessly and with zero upfront or running costs. For more information or press inquiries, please contact team@azuro.org Website: https://azuro.org/
Docs: https://gem.azuro.org
Github: https://github.com/Azuro-protocol
Onchain activity: https://dune.com/azuro/stats About Chiliz Chiliz is the home of SportFi, where sports brands meet decentralized opportunities. Its infrastructure is driven by the Chiliz Chain, the first Layer-1 EVM compatible blockchain for sports and entertainment which now has a diverse ecosystem, fuelled by Chiliz native token CHZ. Its primary product on the Chiliz Chain, Socios.com, hosts a global community of over two million users, which makes it the largest non-finance/trading-centric Web3 consumer-facing product globally by user base. It hase partnerships with countless brands, including the giants of world sport such as FC Barcelona, Paris Saint-Germain, Manchester City, Juventus, S.S.C Napoli, Inter Milan, AC Milan, Arsenal, Atlético Madrid, A.S. Roma and major F1 teams. Website: https://www.chiliz.com/ Contact Azuro team team@azuro.org This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. **LISBON, Portugal, May 9th, 2024/Chainwire/--**Azuro, the leading liquidity layer for onchain predictions, and Chiliz, the world’s premier sports and entertainment blockchain, are partnering up to accelerate the adoption of onchain sport prediction markets. These efforts will allow millions of fans worldwide to further support and cheer for their favorite teams and athletes through fair and transparent prediction apps. Chiliz Chain is renowned for its blockchain solutions that transform fan engagement in sports through features like fan tokens and interactive engagement platforms. Through its flagship venture Socios.com, the network has expanded significantly to support more than 80 sport-related fan tokens and 2M+ ecosystem users. Team-specific fan tokens for the best football clubs, including FC Barcelona, Inter Milan, Juventus, Paris Saint-Germain, Manchester City, and many more, are all currently supported by Chiliz Chain through Socios. The network leverages a Proof of Staked Authority (PoSA) consensus algorithm which allows smart contract developers, validators, stakers, and other stakeholders to actively interact with the chain. Chiliz Chain is built to power sports and entertainment applications with a focus on brand IP and project use-case integrity. For Chiliz, partnering with Azuro represents a step toward tapping into the rapidly growing onchain prediction markets by the hand of the de facto infrastructure layer for sports prediction applications across EVM chains. Its innovative liquidity pool design, advanced tooling and oracle solutions allow apps to launch without upfront investment or running costs, enabling them to focus entirely on user acquisition, engagement and monetization from minute one. Azuro’s robust platform, currently supports over 25 active applications with transaction volumes surpassing $290 million, offers an ideal environment for Chiliz to expand its offerings in the sports and entertainment sectors. As part of this collaboration, Chiliz will be integrated into the Azuro Protocol, adding to the existing supported chains such as Polygon and Gnosis Chain. This integration will enable Chiliz to expand its reach within sports-focused prediction applications. New and existing builders relying on Azuro infrastructure will be able to connect their apps to the Chiliz Chain and allow their users to place transactions with the blockchain’s native token CHZ. "Integrating with Azuro marks a pivotal move for Chiliz Chain to capitalize on the rapidly expanding onchain prediction market," said Alexandre Dreyfus, CEO of Chiliz and Socios.com. "Leveraging Azuro's advanced infrastructure, we're empowering developers to innovate within the sports and gaming sectors." Rossen, a core contributor at Azuro, stated, “The onchain prediction markets have always been strongly tied to the sports and entertainment sector. Working alongside Chiliz Chain, the leading blockchain in this segment, feels like an obvious step for us. Azuro’s robust infrastructure will help expand Chiliz Chain’s usability within the fast-growing onchain prediction markets.” Looking ahead, Azuro and Chiliz will be soon launching a co-sponsored grants program aimed at incentivizing app developers to build on their combined infrastructure. These initiatives, including bounties for the first apps, are designed to fuel further adoption of onchain prediction markets, and aligned with Azuro’s vision for setting new transparency and fairness standards. About Azuro Azuro is the onchain predictions layer. It consists of modular tooling, oracle and liquidity solutions for EVM chains to host powerful prediction and gaming apps. With its unique infrastructure layer approach Azuro makes on-chain predictions and gaming portable and composable. It allows anyone to engage and monetize users by building apps, integrations, and products quickly, permissionlessly and with zero upfront or running costs. For more information or press inquiries, please contact team@azuro.org Website: https://azuro.org/ Docs: https://gem.azuro.org Github: https://github.com/Azuro-protocol Onchain activity: https://dune.com/azuro/stats Website: https://azuro.org/ https://azuro.org/ https://azuro.org/ Docs: https://gem.azuro.org https://gem.azuro.org https://gem.azuro.org Github: https://github.com/Azuro-protocol https://github.com/Azuro-protocol https://github.com/Azuro-protocol Onchain activity: https://dune.com/azuro/stats https://dune.com/azuro/stats https://dune.com/azuro/stats About Chiliz Chiliz is the home of SportFi, where sports brands meet decentralized opportunities. Its infrastructure is driven by the Chiliz Chain, the first Layer-1 EVM compatible blockchain for sports and entertainment which now has a diverse ecosystem, fuelled by Chiliz native token CHZ. Its primary product on the Chiliz Chain, Socios.com, hosts a global community of over two million users, which makes it the largest non-finance/trading-centric Web3 consumer-facing product globally by user base. It hase partnerships with countless brands, including the giants of world sport such as FC Barcelona, Paris Saint-Germain, Manchester City, Juventus, S.S.C Napoli, Inter Milan, AC Milan, Arsenal, Atlético Madrid, A.S. Roma and major F1 teams. Website: https://www.chiliz.com/ Website: https://www.chiliz.com/ https://www.chiliz.com/ https://www.chiliz.com/ Contact Azuro team team@azuro.org This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

Azuro And Chiliz Working Together To Boost Adoption Of Onchain Sport Prediction Markets

The Heroku team has long been an advocate of CI/CD. Their platform integrates with many third-party solutions like GitLab CI/CD or GitHub Actions. In a previous article, I demonstrated how you can configure your Heroku app with GitLab CI/CD to automatically deploy your app to production. In a follow-up article, I walked you through a slightly more nuanced setup involving both a staging environment and a production environment. But if you want to go all in on Heroku, you can use a series of solutions called Heroku Flow to configure all your CI/CD without any third parties. Heroku Flow brings together Heroku pipelines, Heroku CI, Heroku review apps, a GitHub integration, and a release phase. In this article, I’ll show you how to set this up for your own projects. Getting Started Before we begin, if you’d like to follow along, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here, and you can create a GitHub account here. The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub. Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’ll create a Heroku pipeline that includes a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Well done! Creating Our Staging and Production Apps Most engineering organizations use at least two environments: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. Code in the staging environment is then promoted to the production environment to be released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the “Staging” section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now, let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s main branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. In the dialog that appears, make sure the main branch is targeted, and check the box to “Wait for CI to pass before deploy.” In our next step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. Enabling Heroku CI If we’re going to require CI to pass, we better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case, because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps that get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to review your changes manually. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine and run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables the automatic creation of review apps for each PR.
The second box ensures that CI must pass before the review app can be created.
The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline.
We created a staging app and a production app for that pipeline
We enabled automatic deploys for our staging app
We enabled Heroku CI to run tests for every PR
We enabled Heroku review apps to be created for every PR Now, let’s see it all in action. Create a PR in GitHub with any code change you’d like. I made a very minor UI change, updating the heading text from “Heroku Flow Demo” to “Heroku Flow Rules!” Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your “Tests” tab: After the CI pipeline passes, you’ll note another piece of info gets appended to your PR in GitHub. The review app gets deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes in it. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that the staging app was automatically deployed since new code was committed to the main branch. At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users. Click the “Promote to production” button on the staging app. This will open a dialog for you to confirm your action. Click “Promote” to confirm your changes. After promoting the code, you’ll see the production app being deployed. And with that, your changes are now in production for all of your users to enjoy. Nice work! Conclusion What a journey we’ve been through! In this short time together, we’ve configured everything we need for an enterprise-ready CI/CD solution. If you’d like to use a different CI/CD tool like GitLab CI/CD, GitHub Actions — or whatever else you may prefer — Heroku supports that as well. But if you don’t want to reach out to a third-party CI/CD provider, you can now do it all within Heroku with Heroku Flow. The Heroku team has long been an advocate of CI/CD. Their platform integrates with many third-party solutions like GitLab CI/CD or GitHub Actions. In a previous article , I demonstrated how you can configure your Heroku app with GitLab CI/CD to automatically deploy your app to production. In a follow-up article , I walked you through a slightly more nuanced setup involving both a staging environment and a production environment. previous article follow-up article But if you want to go all in on Heroku, you can use a series of solutions called Heroku Flow to configure all your CI/CD without any third parties. Heroku Flow brings together Heroku pipelines, Heroku CI, Heroku review apps, a GitHub integration, and a release phase. configure all your CI/CD In this article, I’ll show you how to set this up for your own projects. Getting Started Before we begin, if you’d like to follow along, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here , and you can create a GitHub account here . create a Heroku account here create a GitHub account here The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-demo
$ npm install
$ npm start $ cd heroku-flow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: http://localhost:5001/ Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’ll create a Heroku pipeline that includes a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Well done! Creating Our Staging and Production Apps Most engineering organizations use at least two environments: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. Code in the staging environment is then promoted to the production environment to be released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the “Staging” section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now, let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s main branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. main In the dialog that appears, make sure the main branch is targeted, and check the box to “Wait for CI to pass before deploy.” In our next step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. main Enabling Heroku CI If we’re going to require CI to pass, we better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case, because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! npm test app.json Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps that get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to review your changes manually. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine and run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables the automatic creation of review apps for each PR. The second box ensures that CI must pass before the review app can be created. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. The first box enables the automatic creation of review apps for each PR. The second box ensures that CI must pass before the review app can be created. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline. We created a staging app and a production app for that pipeline We enabled automatic deploys for our staging app We enabled Heroku CI to run tests for every PR We enabled Heroku review apps to be created for every PR We created a Heroku pipeline. We created a staging app and a production app for that pipeline We enabled automatic deploys for our staging app We enabled Heroku CI to run tests for every PR We enabled Heroku review apps to be created for every PR Now, let’s see it all in action. Create a PR in GitHub with any code change you’d like. I made a very minor UI change, updating the heading text from “Heroku Flow Demo” to “Heroku Flow Rules!” Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your “Tests” tab: After the CI pipeline passes, you’ll note another piece of info gets appended to your PR in GitHub. The review app gets deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes in it. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that the staging app was automatically deployed since new code was committed to the main branch. main At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users. Click the “Promote to production” button on the staging app. This will open a dialog for you to confirm your action. Click “Promote” to confirm your changes. After promoting the code, you’ll see the production app being deployed. And with that, your changes are now in production for all of your users to enjoy. Nice work! Conclusion What a journey we’ve been through! In this short time together, we’ve configured everything we need for an enterprise-ready CI/CD solution. If you’d like to use a different CI/CD tool like GitLab CI/CD, GitHub Actions — or whatever else you may prefer — Heroku supports that as well. But if you don’t want to reach out to a third-party CI/CD provider, you can now do it all within Heroku with Heroku Flow. do it all

How I Got My CI/CD Act together With Heroku Flow

Over the last several months I had the privilege of editing “False Alarm,” Todd Feathers’ nuanced, thought-provoking investigation into Wisconsin’s racially inequitable “dropout algorithm.” The Dropout Early Warning System (DEWS) assesses every incoming high schooler in Wisconsin and issues a numerical score as well as a color-coded label: green for low risk, yellow for moderate risk, or red for high risk of dropping out. Irrespective of race, DEWS is wrong nearly three quarters of the time when it predicts a student won’t graduate on time. But it was also designed to use factors like race, gender, income, and attendance, to cast a wide net—one that is ensnaring Black and Latino kids far more frequently. (You can read more of our takeaways and findings here.) I’ve been mulling over comments from the state’s education spokesperson, Abigail Swetz, who declined to answer detailed questions but emailed us this: “Is DEWS racist? No, the data analysis isn’t racist. It’s math that reflects our systems. The reality is that we live in a white supremacist society, and the education system is systemically racist. That is why the DPI needs tools like DEWS and is why we are committed to educational equity.” Here’s what she said in response to our findings and further questions: “You have a fundamental misunderstanding of how this system works. We stand by our previous response.” She did not explain what that fundamental misunderstanding was. In the week since we published Todd’s investigation, none of the facts of the story have been challenged. It’s difficult for me to square the underlying sentiment suggesting that because our world is racist, even the tools and systems attempting to achieve equity should be excused when they perpetuate that racism instead of correcting it. That leaves us trapped in a loop in which no one is directly accountable for harm. It’s like that meme with all the Spider-Mans pointing at each other. Young people of color featured in this investigation voiced that DEWS was just another way they felt dismissed, disregarded, and judged by the very educators tasked with caring for them and their futures. Kennise Perry, 21, attended Milwaukee Public Schools, which are 49 percent Black, before moving to the suburb of Waukesha, where the schools are only 6 percent Black. Perry told Todd her childhood was difficult, her home life sometimes unstable, and her schools likely considered her a “high risk” student. She summed up her school experience as “traumatic.” Here’s what else she shared: “But I feel that the difference between people who make it and people who don’t are the people you have around you, like I had people who cared about me and gave me a second chance and stuff. [DEWS] listing these kids high risk and their statistics, you’re not even giving them a chance, you’re already labeling them.” Labels stick around. I still remember every elementary school teacher who gave me a “U” for unsatisfactory in the self-control category on progress reports and how disappointed my mother always was. Or my fourth-grade teacher who told me my hair beads were too loud and asked me to get them removed. Or the hate mail Black students received on Valentine’s Day of my first year of high school. In response to racist incidents that they felt the school’s administration wasn’t properly addressing, Mia Townsend and Maurice Newton, the juniors in our lead image, took matters into their own hands and started Cudahy High School’s first Black Student Union. As Todd put it, the BSU students “organically provided the same kind of supportive interventions for each other that the state hoped to achieve through its predictive algorithms.” Newton persuaded Townsend, an honor roll student, to ask to enroll in AP English next year—she was initially planning to avoid these courses. There’s something both beautiful and tragic about kids stitching their own safety net, because they shouldn’t have to. School administrators should be the ones to make sure a student like Townsend believes she’s ready for AP. The community these students are building is a lifeline, but it’s a result of adults not fully considering their students’ experiences or well-being. The racial bias undergirding Townsend and Newton’s reason for founding the BSU, the inequity at the root of DEWS, the trauma Perry experienced throughout her schooling—none of that can or should be dismissed because our world is racist and anti-Black. If anything, it’s why we have to continuously challenge our biases, including the systems—from algorithms to academic settings—that perpetuate them. Sincerely, Ko Bragg Editor The Markup By Ko Bragg Also published here Photo by Andrés Canchón on Unsplash Over the last several months I had the privilege of editing “ False Alarm ,” Todd Feathers’ nuanced, thought-provoking investigation into Wisconsin’s racially inequitable “dropout algorithm.” False Alarm The Dropout Early Warning System (DEWS) assesses every incoming high schooler in Wisconsin and issues a numerical score as well as a color-coded label: green for low risk, yellow for moderate risk, or red for high risk of dropping out. Irrespective of race, DEWS is wrong nearly three quarters of the time when it predicts a student won’t graduate on time. But it was also designed to use factors like race, gender, income, and attendance, to cast a wide net—one that is ensnaring Black and Latino kids far more frequently. (You can read more of our takeaways and findings here. ) designed here. I’ve been mulling over comments from the state’s education spokesperson, Abigail Swetz, who declined to answer detailed questions but emailed us this: “Is DEWS racist? No, the data analysis isn’t racist. It’s math that reflects our systems. The reality is that we live in a white supremacist society, and the education system is systemically racist. That is why the DPI needs tools like DEWS and is why we are committed to educational equity.” Here’s what she said in response to our findings and further questions: “You have a fundamental misunderstanding of how this system works. We stand by our previous response.” She did not explain what that fundamental misunderstanding was. In the week since we published Todd’s investigation, none of the facts of the story have been challenged. It’s difficult for me to square the underlying sentiment suggesting that because our world is racist, even the tools and systems attempting to achieve equity should be excused when they perpetuate that racism instead of correcting it. That leaves us trapped in a loop in which no one is directly accountable for harm. It’s like that meme with all the Spider-Mans pointing at each other. Young people of color featured in this investigation voiced that DEWS was just another way they felt dismissed, disregarded, and judged by the very educators tasked with caring for them and their futures. Kennise Perry, 21, attended Milwaukee Public Schools, which are 49 percent Black, before moving to the suburb of Waukesha, where the schools are only 6 percent Black. Perry told Todd her childhood was difficult, her home life sometimes unstable, and her schools likely considered her a “high risk” student. She summed up her school experience as “traumatic.” Here’s what else she shared: “But I feel that the difference between people who make it and people who don’t are the people you have around you, like I had people who cared about me and gave me a second chance and stuff. [DEWS] listing these kids high risk and their statistics, you’re not even giving them a chance, you’re already labeling them.” Labels stick around. I still remember every elementary school teacher who gave me a “U” for unsatisfactory in the self-control category on progress reports and how disappointed my mother always was. Or my fourth-grade teacher who told me my hair beads were too loud and asked me to get them removed. Or the hate mail Black students received on Valentine’s Day of my first year of high school. hate mail In response to racist incidents that they felt the school’s administration wasn’t properly addressing, Mia Townsend and Maurice Newton, the juniors in our lead image, took matters into their own hands and started Cudahy High School’s first Black Student Union. As Todd put it, the BSU students “organically provided the same kind of supportive interventions for each other that the state hoped to achieve through its predictive algorithms.” Newton persuaded Townsend, an honor roll student, to ask to enroll in AP English next year—she was initially planning to avoid these courses. There’s something both beautiful and tragic about kids stitching their own safety net, because they shouldn’t have to. School administrators should be the ones to make sure a student like Townsend believes she’s ready for AP. The community these students are building is a lifeline, but it’s a result of adults not fully considering their students’ experiences or well-being. The racial bias undergirding Townsend and Newton’s reason for founding the BSU, the inequity at the root of DEWS, the trauma Perry experienced throughout her schooling—none of that can or should be dismissed because our world is racist and anti-Black. If anything, it’s why we have to continuously challenge our biases, including the systems—from algorithms to academic settings—that perpetuate them. Sincerely, Ko Bragg Editor The Markup By Ko Bragg By Ko Bragg Ko Bragg Also published here Also published here here Photo by Andrés Canchón on Unsplash Photo by Andrés Canchón on Unsplash Andrés Canchón Unsplash

How to Stitch Your Own Safety Net: Bonding Together

I'm excited to share with you a few extremely good easy and effective ways to work collectively as a group, even when we're miles apart. Remote pairings are becoming more common in recent times, and it is essential to have the right techniques in location to hold matters easily. So, let’s dive into some easy hints to act as professionals, no matter where we are! Communication Is Key First things first, let's communicate about communication. When we are not inside the same room, it's crucial to stay connected and preserve every other inside the loop. One smooth manner to do that is through the usage of messaging apps like Slack or Microsoft Teams. These tools allow us to share brief messages, files, and even hop on video calls every time we need to talk face-to-face. Another critical element of communication is setting clean expectancies. I find it useful to define our goals and cut-off dates at the start of every week, so anyone knows what they want to accomplish and by when. In this manner, we are able to all work on target and help everyone. Collaborative Tools for the Win Now, let’s talk about equipment. There are a lot of super software programs out there designed especially for remote teams, and they could make a huge difference in how we work together. For instance, challenge control tools like Trello or Asana are top-notch for preserving responsibilities and cut-off dates. We can create boards or lists and assign duties to group members. Another handy tool is Google Drive or Dropbox for sharing and collaborating on files. Instead of emailing files from side to side, we are able to all work on the identical report simultaneously, leaving feedback and guidelines for every different in real-time. It's a sport-changer for remote collaboration! Virtual Team-Building Activities Last but not least, let’s talk about team building. Just due to the fact we are no longer within the same workplace does not suggest we can not have amusing together! There are plenty of virtual group-building sports we can try to enhance our bond as a team. For example, we could schedule ordinary video calls simply to catch up and chat about non-paintings-associated topics. It's a great way to get to understand each other better and build acceptance and camaraderie. We could also attempt gambling online games or quizzes together. There are tons of websites and apps out there that offer multiplayer video games or triviality quizzes that we can play as a crew. It's a fun way to interrupt the ice and foster a sense of teamwork. And consider virtual crew lunches or espresso breaks! We can all hop on a video call and enjoy a meal or a cup of espresso collectively, similar to what we would if we had been within the identical office. It's a simple but powerful manner to stay linked and take a break from work for a bit. In the end, far-off group collaboration does not have to be complex. By prioritizing verbal exchange, using the right gear, and incorporating some fun crew-building sports into our habits, we can pair collectively successfully no matter where we are. So let's put those techniques into action and make far-off pairings feel like a breeze! I'm excited to share with you a few extremely good easy and effective ways to work collectively as a group, even when we're miles apart. Remote pairings are becoming more common in recent times, and it is essential to have the right techniques in location to hold matters easily. So, let’s dive into some easy hints to act as professionals, no matter where we are! Communication Is Key First things first, let's communicate about communication. When we are not inside the same room, it's crucial to stay connected and preserve every other inside the loop. One smooth manner to do that is through the usage of messaging apps like Slack or Microsoft Teams . These tools allow us to share brief messages, files, and even hop on video calls every time we need to talk face-to-face. Slack Microsoft Teams Another critical element of communication is setting clean expectancies. I find it useful to define our goals and cut-off dates at the start of every week, so anyone knows what they want to accomplish and by when. In this manner, we are able to all work on target and help everyone. Collaborative Tools for the Win Now, let’s talk about equipment. There are a lot of super software programs out there designed especially for remote teams , and they could make a huge difference in how we work together. For instance, challenge control tools like Trello or Asana are top-notch for preserving responsibilities and cut-off dates. We can create boards or lists and assign duties to group members. remote teams Trello Asana Another handy tool is Google Drive or Dropbox for sharing and collaborating on files. Instead of emailing files from side to side, we are able to all work on the identical report simultaneously, leaving feedback and guidelines for every different in real-time. It's a sport-changer for remote collaboration! Google Drive Dropbox Virtual Team-Building Activities Last but not least, let’s talk about team building. Just due to the fact we are no longer within the same workplace does not suggest we can not have amusing together! There are plenty of virtual group-building sports we can try to enhance our bond as a team. For example, we could schedule ordinary video calls simply to catch up and chat about non-paintings-associated topics. It's a great way to get to understand each other better and build acceptance and camaraderie. For example, we could schedule ordinary video calls simply to catch up and chat about non-paintings-associated topics. It's a great way to get to understand each other better and build acceptance and camaraderie. We could also attempt gambling online games or quizzes together. There are tons of websites and apps out there that offer multiplayer video games or triviality quizzes that we can play as a crew. It's a fun way to interrupt the ice and foster a sense of teamwork. sense of teamwork. And consider virtual crew lunches or espresso breaks! We can all hop on a video call and enjoy a meal or a cup of espresso collectively, similar to what we would if we had been within the identical office. It's a simple but powerful manner to stay linked and take a break from work for a bit. In the end, far-off group collaboration does not have to be complex. By prioritizing verbal exchange, using the right gear, and incorporating some fun crew-building sports into our habits, we can pair collectively successfully no matter where we are. So let's put those techniques into action and make far-off pairings feel like a breeze!

Stories, News & Mentions about VRTOGETHER

Vrtogether’s Stories on HackerNoon