EXPERIENCE IS THE MESSAGE. RELAYTO engages advanced algorithms to automatically revamp static content into interactive microsites that boost viewer engagement 24/7 - no coding required. https://relayto.com/showcase Our secret sauce: 1. Content Enrichment - Turn “digital paper” into digital experiences enriched with interactivity, non-linear navigation and media. 2. All-in-one Cloud Hubs - Convert files into super-intelligent URL optimized for omni-channel sharing, access & control. 3. Advanced Analytics - 360-degree analytics around engagement of your content for better optimization. Think of Optimizely for web content. In the background, RELAYTO is also creating a new digital medium for one-one interactive storytelling, focused on removing friction for both authors and readers. Check out http:/rla.to/pitch or book a meeting with us: https://rla.to/meet-with-relayto

RELAYTO

relayto

Kuma Meshes Head-On - Everything You Need to Know

কুমা মেশেস হেড-অন - আপনার যা জানা দরকার

Kuma Meshes Frontal – Alles, was Sie wissen müssen

Kuma se enfrenta de frente: todo lo que necesitas saber

Kuma Meshes de front – Tout ce que vous devez savoir

कुमा मेशेस हेड-ऑन - वह सब कुछ जो आपको जानना चाहिए

クマが正面からメッシュ化 - 知っておくべきことすべて

Kuma Meshes 정면 대결 - 알아야 할 모든 것

Kuma Meshes Head-On - Tudo o que você precisa saber

Kuma Meses в лоб – все, что вам нужно знать

Kuma Kafa Başına Meshes - Bilmeniz Gereken Her Şey

Kuma Meshes Head-On - Mọi thứ bạn cần biết

Kuma Meshes 迎面而来——您需要了解的一切

This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Akash Chikhalikar, Graduate School of Engineering, Department of Robotics, Tohoku University; (2) Ankit A. Ravankar, Graduate School of Engineering, Department of Robotics, Tohoku University; (3)  Jose Victorio Salazar Luces, Graduate School of Engineering, Department of Robotics, Tohoku University; (4) Yasuhisa Hirata, Graduate School of Engineering, Department of Robotics, Tohoku University. Table of Links Abstract & Introduction Related Work Semantic Mapping Framework Multi-Target Search Experimental Studies Conclusions and Discussions, Acknowledgment and References V. EXPERIMENTAL STUDIES The following section describes the experimental details, starting with hardware configuration, followed by quantitative results and analysis. A. Hardware Configuration We use a Turtlebot2 platform with Kobuki base for our experiments. The onboard sensors include a RGB-D camera (Azure Kinect), a laser range scanner (RPLIDAR S2). The encoder information from the robot base is used to compute the odometry. The data acquisition from sensors and command relay to the robot is performed on the NVIDIA Jetson AGX Xavier as the client. The backend computations as well as the frontend visualization were carried out on a server CPU with NVIDIA 3090RTX graphics unit with an i9-12900K processor. The ROS distributed computing network ensured time synchronized communication between the server and the client. B. Living Lab- Simulated indoor environment All tests were performed in a simulated indoor environment called the ‘Aobayama Living Lab’ [2] at Tohoku University. The goal is to create a concept for future welfare facilities, as shown in Fig. 5. The Living Lab included household objects such as tables, chairs, sofas, beds, TVs, lamps, and cabinets. The facility emulates various areas, including toilets, bathrooms, kitchens as well as an outdoor environment with stairs, slopes, and rough terrain. The dataset generated from the Living Lab will be used to facilitate long-term navigation for service robots. C. Experimental Setup We conducted numerous experiments with different initial positions to understand the influence of our heuristic and navigation strategies. Each data point shown in the next subsection is obtained after averaging the results of five tests conducted in every scenario. Averaging eliminates any bias due to the slight randomness of the path planners and the minor differences in the starting positions (< 5cm) in each run. The distance traveled and the time required for the robot to search each target is recorded. The positions of the targets, i.e., cup and remote, are kept unchanged. D. Results and Analysis The results are divided into two groups. In the first part, we compare the performance of our novel heuristic with a baseline probabilistic greedy search. Figure 6 shows the results of a comparative study. Compared to the baseline, the proposed heuristic led to an average decline of 31.67% in the time taken, and 40.5% decrease in distance travelled to find a cup. Similar reductions of 26.35% and 29.3% were found in time required and distance travelled for searching remote. Thus, our heuristic is significantly superior than probabilistic baselines for multitarget search. Next, we compare the differences in target search with respect to the priorities set by the user. We initialize the target search from ten random locations in the indoor environment and change the priority of the search for each scenario. The results are shown in Figures 7a and 7b below. Our studies show that on an average a time reduction of 12.05s (33.5%) is observed when the user prioritizes finding the cup. In case of prioritising remote, a time reduction of 10.5s (26.5%). observed when compared with an equal priority search. When the user prioritises cup, the first-hit (i.e finding the target at the first landmark visited) percentage was 60% as compared to 40% for a equal-priority search. The cumulative time spent increased by 8.94s when prioritising remote and by 4.13s when prioritising cup as compared to equal priority search. Additionally, if the robot were to prioritize finding the remote, it took 25.8s more than the equal priority search to find the cup. Thus, it can be inferred that if the user intends to save energy or cumulative time rather than find one target at the earliest, an equal priority directive should be given. We assess the distance efficiency of our search strategy by calculating the Success weighted by Path Length (SPL) metric as follows: = Length of path followed by Robot L Figure 8 shows the SPL for target search (for both targets) depending on the priority set by the user. It is observed that the SPL increases by 0.16 (24.84%) when the user tasks the robot to search for a cup with priority, as compared to an equal priority search. An increase of 0.14 (19.5%) in the SPL is observed when prioritsing remote in the target search. In a cross-analysis, it is seen that the SPL decreases by 0.18 (20.2%) while searching for remote and 0.42 (51.5%) while searching for cup if the user prioritizes searching for the other object. The sharper SPL decline for cup can be attributed to its real location being closer to multiple landmarks as opposed to the remote.

Preferential Multi-Target Search in Indoor Environments using Semantic SLAM: Experimental Studies

The wait is over! - it’s time to celebrate the champion startups of the world. Shout out to all of the participants in our ! You did a wonderful job showcasing your incredible startups and powering through another year. 2023 Startups of the Year is a community-driven voting platform brought to you by HackerNoon that recognizes and celebrates tech startups changing technology and the world for the better. The award started on May 8th, 2023, where the internet nominated and voted for 30k startups around the world. The voting period remained open until December 31, 2023, and now we are here with the winner announcement after a comprehensive evaluation by the HackerNoon team. Startups of the Year 2023 To see the top 3 startups in each respective city, visit and pick a city. hackernoon.com/startups You’ll get a little surprise 😉 Here are the Startups of the Year Regional Announcements: North America Europe Asia Africa South America Oceania Misc/Remote From all of us at HackerNoon, thank YOU for your excellent campaign perseverance 🥺 This year has been awesome! Startups of the Year 2023 is concluded with 623k+ total votes, up from 215k+ votes in the inaugural startup competition. We look forward to seeing you again in the next campaign (stay tuned 😉)! Without further ado, let us kick off the announcement by celebrating the cities with top votes per region for 2023 🎉 North America (11,697 votes): Winner: Bloomfilter Cleveland, Ohio (8,835 votes) - Winner: SerpApi Austin, Texas , California (5,564 votes) - Winner: Finch San Francisco (4,258 votes) - Winner: RELAYTO SoMa, California - (3339 votes) Winner: Windscribe Toronto, Canada, North America (3304 votes) - Winner: Vouched Seattle (2716 votes) - Winner: Seccuri Palo Alto, CA, North America (2671 votes) - Winner: Salsa Valley Miami, FL, North America (2,613 votes) - Winner: Majhi Group Manhattan, New York (2423 votes) - Winner: Flieber, Inc. New York City, NY, North America See the complete announcement for the . Startups of the Year, North America, here Europe (45,612 votes) - Winner: Algomo London, UK (2,344votes) - Winner: Data Lake Warsaw, Poland (1,955 votes) - Winner: Hoken Tech Bari, Italy (1716 votes) - Winner: Not8 Amsterdam, Netherlands (1657 votes) - Winner: KYVE Frankfurt Am Main, Germany (1566 votes) - Winner: BazaIT Kyiv, Ukraine (1496 votes) - Winner:  Unity Network Tallinn, Estonia (1,478 votes) - Winner: Volcaino Ghent, Belgium (1,288 votes) - Winner: Owl Me Dublin, Ireland (1198 votes) - Winner: Groover Paris, France See the complete announcement for the . Startups of the Year, Europe, here Oceania (3,350 votes) - Winner: Sharepass Melbourne (2,107 votes) - Winner: The Catfisher Project Perth, Australia (220 votes) - Winner: Gemini AI Solutions Auckland, New Zealand, Oceania (213 votes) - Winner: Nexustorage Wellington, New Zealand, Oceania (138 votes) - Winner: Coviu Sydney (124 votes) - Winner: Bopple Brisbane, Australia, Oceania (124 votes) - Winner: Regional CFO New South Wales, Australia, Oceania (106 votes) - Winner: Edit on the Spot Gold Coast, Australia, Oceania (93 votes) - Winner: Knowledge Satnav Canbera, Australia, Oceania , Australia, Oceania (48 votes) - Winner: Peptalk360 North Melbourne, Melbourne See the complete announcement for the . Startups of the Year, Oceania, here Asia (16,345 votes) - Winner: Serenity Shield Singapore (13,588 votes) - Winners: QUIXY Telangana, India (10,168 votes) - Winner: HealthySure Mumbai, India (3,865 votes) - Winner: InterviewBuddy Visakhapatnam, India (3,733 votes) - Winner: Omniflo Bengaluru, India (4589 votes) - Winner: MeNow Tel Aviv (3877 votes) - Winner: ForestVPN Dubai (2478 votes) - Winner: TechGraph Powai, Mumbai, India (1004 votes) - Winner: Reelo Ahmedabad, GJ, India (875 votes) - Winner: Debt Hunter Hong Kong, China See the complete announcement for the . Startups of the Year, Asia, here Africa (8,179 votes) - Winner: GO PLATFORM Algiers, Algeria (767 votes) - Winner: Tudu Accra, Ghana (415 votes) - Winner: Treford Lagos, Nigeria (265 votes) - Winner: Phalconwise Ogbomosho, Nigeria (157 votes) - Winner: AbuErdan Cairo (151 votes) - Winner: Eazipay Lekki (144 votes) - Winner: KaziConnect Dar es Salaam, Tanzania (101 votes) - Winner: faceATT Gauteng, South Africa (79 votes) - Winner: Dimagi Cape Town (71 votes) - Winner: Sabi Addis Ababa See the complete announcement for the . Startups of the Year, Africa, here South America (376 votes ) - Winner: UpGirl Santiago, Chile (217 votes) - Winner: Klever Sao Paulo, Brazil (191 votes) - Winner: Tributo Simple Buenos Aires, Argentina (127 votes) - Winner: Light-it Montevideo, Uruguay (87 votes) -Winner: Thousand Antioquia, Colombia (108 votes) - Winner: GetLavado Lima (101 votes) - Winner: Cogniflow Medellin (73 votes) - Winner: TPAGA Bogota (73 votes) - Winner: Reliv Quito (47 votes) - WInner: Quantex Cordoba See the complete announcement for the . Startups of the Year, South America, here Misc/Remote: Featured Startups (1500 votes) - Winner: CIC Chain Remote, Earth (1193 votes) - Winner: Reship Colony US Misc (146 Votes) - Winner: Partful UK, Misc (116 votes) - Winner: GoMining British Virgin Islands Misc (283 Votes) - Winner: tomorrowSpace Germany Misc (225 votes) - Winner: Dtravel Cayman Islands See the complete announcement for Misc/Remote startups . here Once again, HUGE CONGRATULATIONS and BIG PROPS to all of the top Startups of each region this year! The whole team at HackerNoon would like to thank you for your perseverance in the campaign, and we look forward to seeing you in the next campaign. About HackerNoon’s Startups Of The Year Startups of The Year is HackerNoon’s Flagship community-driven event celebrating startups that survived and thrived in 2023. 30,000 startups across 4200+ cities and six continents participated this year to be crowned the best startup in their city. Visit our page to learn more. FAQ Companies that blog more get 67% more leads - Jumpstart your company’s blogging journey by purchasing our . Business Blogging Package The 2023 Startups Of The Year is sponsored by: . . The winners get a free .Tech Domain, a HackerNoon NFT, and a Tech Company News Page. TECH Domains

Stand Up for the Champion Startups of the Year! 

বছরের চ্যাম্পিয়ন স্টার্টআপের জন্য দাঁড়ান!

Setzen Sie sich für die Champion-Startups des Jahres ein!

¡Defiende a las startups campeonas del año!

Défendez les startups championnes de l’année !

वर्ष के चैंपियन स्टार्टअप के लिए खड़े रहें!

今年のチャンピオンスタートアップのために立ち上がろう!

올해의 챔피언 스타트업을 위해 일어서세요!

Defenda as startups campeãs do ano!

Встаньте на защиту стартапов-чемпионов года!

Yılın Şampiyon Startup'ları için Ayağa Kalkın!

Hãy ủng hộ các công ty khởi nghiệp vô địch của năm!

为年度冠军初创企业挺身而出！

There is a recent paper, , discussing synaptic pruning, where the authors summarized that: Activity-dependent local protection and lateral inhibition control synaptic competition in developing mitral cells in mice "Synaptic competition is known to facilitate synapse elimination; however, it has remained unknown how different synapses compete with one another within a post-synaptic cell. Here, we investigate how a mitral cell in the mouse olfactory bulb prunes all but one primary dendrite during the developmental remodeling process. We find that spontaneous activity generated within the olfactory bulb is essential." There are a few types of neurons in the brain, numbering in the billions with trillions of synapses, but they cannot be said to be directly involved in functions. There are already neurons identified across brain circuits with higher functional responsibilities for varying necessities. However, these localization finds have not led to solving consciousness or mental health problems. Impulses Explained The direct factors for all the functions of the brain are impulses. The electrical and chemical impulses of nerve cells and their interactions, which is also what the mind is, conceptually. There is no function of the brain that does not involve impulses. There are sets of impulses for functions, exceeding the singular actions of one or just a neurotransmitter. There are functions, of say acetylcholine, but what makes determination in experiences are sets of impulses, with the involvement of acetylcholine, not its singular oversight, even though it makes contributions. Conceptually, wherever there are nerve cells, what is most important are the features of their impulses and their interactions. This is what makes a memory different from modulation, or an emotion from a feeling. In a set, the electrical impulses relay to 'acquire' chemical impulses, with specifications for intensity, shifts, sides, spots, and so on, giving rise to an emotion in one case, and a feeling in another. These specifications are also responsible for how memory is encoded or retrieved. There are features of sets of impulses, like splits, sequences, prioritization, and others, that determine how impulses give off experiences, including mental disorders. There is no difference between how impulses give rise to memory and how it The key difference is specificity for sets of impulses. This is also the reason some parts of the brain are more adapted to some functions than others. does for sentience. Synaptic connections are forms of sequential threads, where matches for impulses in a set may determine something cliché or novel. In general, the function of the mind is to know, applicable to thoughts, feelings, memory, emotions, and so forth. Consciousness Consciousness for being and experience are also knowing processes, possible by the interaction of impulses, with specifications for sets. Conceptually, interactions that determine consciousness may have incoming electrical impulses 'fill' certain bends, for some in a set, while for location in space, could be a rotation, for memory could be a sequence or path of travel for aligning synapses, and so forth. The interactions of impulses across brain centers are not different. This makes the mechanism of consciousness similar, only with a difference in what sets of impulses do when chemical impulses are acquired. Feature image source

LLMs, Sentience: How Do Impulses Give Rise to Consciousness?

There is a recent article on where the authors stated that, "One thing hasn’t changed: Machines are not conscious. The ability to generate human-like responses is a result of what computers do best: finding patterns in enormous data sets. It’s a very sophisticated version of Google auto-complete, able to guess the next series of words that best satisfies what the user wants." Bloomberg , AI Isn’t Sentient. Blame Its Creators for Making People Think It Is , "Pretending to be human does not make a thing conscious. The science of how the brain works is one route to understanding how and why we experience emotions like joy and suffering. It offers clues about what sparks creativity, imagination, and curiosity. But even neuroscience has its limits. Computers can’t think or feel the ways humans do." Though it would be more appropriate to say the mind drives experiences, as well as creativity, not the brain, the ultimate decision maker if AI is sentient is what consists of sentience and if AI has some of it. Consciousness is driven by the human mind. Divisions of conscious experiences include feelings, emotions, perceptions, sensations, memory, intelligence, creativity, and so forth. The divisions result in a total. Though some are subsumed within others—like intelligence and creativity within memory—each division has a rate, varying across states of consciousness. Consciousness is the measure of a system's ability to know, with a maximum value of 1. Sentience or consciousness is defined by the act of knowing. Even if something isn't fully within one's awareness or attention, it must still be known within the mind. When something like "joy or suffering" is known, prioritization may determine the extent to which it is experienced. Subjective experiences, such as the sense of self or the "I" in experiences, are provisioned by the mind and must be known. However, in some experiences, there is detachment and no sense of self, meaning the property was not acquired. Conceptually, the components of the human mind are quantities and properties. Quantities relay to acquiring properties to degrees to drive experiences. The labels of memory, emotion, feeling, reaction, and so forth are properties obtainable to degrees across mind locations. On the mind, properties are simply obtained—the labels are useful to delineate—but the components of the mind make determinations. Simply, consciousness can be expressed as: t + M + F + E = 1 where t is thought, but never a standalone parameter, because it is often a quantity-bearing property. M, F, and E are memory, feelings, and emotions respectively. The human mind components prepare t, M, F, and E. Animal and plant equivalents are prepared by components with similar functions. systems lack the quantities and properties of the human mind, but they possess M, which arrives through a different pathway. Their diverse forms of M manifest in their communication, task execution, and ability to relate and understand. LLM LLMs' outcomes may result from 'finding patterns in enormous data sets,' yet they exhibit aspects of human intelligence. In the human mind, experiences are not solely determined by external situations; they depend on the properties that a quantity acquires. Loneliness, for instance, may not be solely caused by external factors but by internal ones as well. Thus, an outcome can be experienced despite differing external circumstances or varying degrees of intensity. LLMs' high M is likely greater than the sentience of some animals and plants. In fact, their high M already mirrors aspects of human intelligence, surpassing the M of various plants and animals. Lead image source.

Sentience: Evaluating LLMs, AI

OK hear me out, I know vulnerability management is an old practice. Why are we even talking about it, it’s not broken, right? For most companies, it is very broken even if it appears to be working. These broken vulnerability management programs are so similar that I bet I can describe broken vulnerability management program, without ever talking to you about it.  I bet it contains some of the following elements: YOUR 11 GB of excel spreadsheets (x10 if you are a larger enterprise) Massive email footprint, eating up about 1/3 of your inbox storage 3 that you can’t get anyone to take seriously truly critical vulnerabilities Tenable/Rapid7/Qualys/Green Bone/et al producing weekly or monthly scan reports A feeling of total despair…. I have lived and breathed vulnerability management for most of my career. At times, it was the majority of my work. Other times, it’s just a small part. But the thread remains, it feels like I am always talking about CVSS scores and trying (usually failing) to relay to anyone who will listen how these are just starting points for assessing vulnerabilities.  In reality, CVSS scores can often be so blind to architectures, security controls, and business practices that they do more harm than good! Luckily for you, I am not the type of person to raise my hand and call out a broken process without also bringing a good solution to the table. I present to you, SSVC or Stakeholder-Specific Vulnerability Categorization. A primer on SSVC Carnegie Mellon University's (SEI) and the have collaborated to create the Stakeholder-Specific Vulnerability Categorization (SSVC) system. This system is built to provide the cyber community with a vulnerability analysis methodology that takes into account the exploitation status, safety impacts, and prevalence of the affected product for each vulnerability. Later on, in 2020, the CISA collaborated with SEl to develop its own distinct SSVC decision tree for analyzing vulnerabilities affecting the US government, state, local, tribal & territories (SLTT), and critical infrastructure organizations. Software Engineering Institute CISA That is the definition provided by SEI & CISA. What this means in practical terms is, we now have a way of adding valuable context to the vulnerability assessment process. This is so critical to the improvement of vulnerability management, it can not be overstated.  This isn’t an evolution of a broken system, this is a revolution! SSVC in a nutshell CISA uses stakeholder-specific vulnerability information to identify, assess, and organize the cybersecurity risks faced by the country's critical infrastructure.  To assist them in better understanding and managing the cybersecurity threats faced by the US government, CISA provides stakeholder-specific vulnerability information to other federal agencies, state and local governments, the corporate sector, and foreign partners. CISA uses a slightly different model than that developed originally in conjunction with SEI. This model sorts vulnerabilities into four potential “states”. You can use this same model in your organization, with no additional work needed. To get started, you must first spend a few minutes understanding that vulnerabilities are sorted into “states”, each state has a descriptive set of actions that must be taken on the vulnerabilities in this state. States The vulnerability states can be thought of as general descriptions of how to treat a vulnerability. It’s important to note that we don’t see any number systems like the CVSS 0-10. Numbers poorly describe the nuanced qualities of a vulnerability, these states however do a much better job. When a vulnerability lands in one of these states, you simply read the language of the state and then apply that to the identified vulnerability. No interpretation, no additional consideration, just take action! The following four states are sorted from what is essentially “Informational” to “Critical” (top to bottom). At this time, no action is necessary to respond to the vulnerability. The company would keep an eye on the vulnerability and reevaluate it if new information surfaces. CISA advises addressing “Track” vulnerabilities during routine meetings to verify the state is still applicable. Track: The vulnerability has unique properties that may call for closer observation of any changes. CISA suggests that security patches should be applied to “Track***”** vulnerabilities during the next patching or outage window. Track*: : The organization's internal supervisory level personnel must pay attention to the vulnerability. The activities that must be undertaken include asking for help or gathering additional details regarding the vulnerability, and they may include publishing a notification internally or internationally. The CISA advises addressing “Attend” vulnerabilities with some urgency, earlier than the normal patching window. Attend : Internal, supervisory, and leadership-level members of the organization must pay attention to the vulnerability. Requesting assistance or details about the vulnerability, as well as disseminating a notification internally and/or externally, are required. Internal groups would often gather to decide on the overall reaction before carrying out the decisions made. “Act” vulnerabilities should be fixed as soon as feasible. Act Applying SSVC in your organization? While CISA and CMU SEI have developed this framework, they are still working out exactly how it should be used. Currently, they suggest using a decision tree workflow, which they call the SSVC Calculator. The SSVC calculator is a simple, intuitive graphical way to answer yes-no questions using easily obtained data.  This is what enables a more thorough analysis of vulnerabilities, with less incumbent skill (i.e. you don’t need a ton of experience to correctly assess a vulnerabilities severity). To use the calculator, you hover over the blue dots (decision points) to get information that will help make a decision.  Once a decision has been made, clicking the appropriate blue dot enters an answer and a new series of decisions (dots) will show up. In this example, you can see that by answering just four questions: No exploitation exists yes it’s Automatable it has a partial technical impact the assets involved are a medium level of importance We are able to determine this (made-up) vulnerability arrives at a “Track” state. With the “Track” state vulnerability, we would keep an eye on it and update the calculation should new info come out otherwise no actions would be taken. Wrapping this up SSVC is a step forward, as noted it is not the evolution of the vulnerability management space but instead a revolution of vulnerability management.  CVSS scores were a good starting point, but as we have seen time and time again, they are a poor indicator of true criticality.  Using the SSVC decision tree model, consistent, accurate vulnerability assessment can be achieved with less expertise! Also published here.

How to Fix Your Broken Vulnerability Management

This article is the 3rd in a series related to building a wireless thermostat in Rust, running on a Raspberry Pi – although this one has very little to do with the Raspberry Pi and is more relevant to any multi-threaded application. When creating my application, I implemented a simple and effective design for controlling multi-threaded access to shared memory. You can find the previous articles here: , and first article - Raspberry Pi Wireless Thermostat in Rust . second article - Cross Compiling Made Easy I have a few code snippets below, but you can find the entire code repository . on GitHub First, the back story: When designing a multi-threaded application, one of the core considerations is how the different threads share data. There’s always something that the threads share – you’re spinning off threads to work on a shared problem, after all. If nothing else, configuration data or database connection pools have to be shared. There are two main ways of approaching this problem. – channels between threads allow data to be sent and received between them. Message passing is the mechanism that golang prefers, as the golang documentation states: “Do not communicate by sharing memory; instead, share memory by communicating.” Rust supports creating channels; you can find more information in the Rust Book’s chapter on . Message Passing message passing – a set of data identified as a shared state. Each thread access a shared data area through thread-safe protection mechanisms – typically a Mutex. Locks on the data allow you to access the data safely, reading or updating the data as needed, and then the lock is released. Only one thread can read or write the data at a time. The Rust Book’s section describes these mechanisms. Shared-State shared state Both approaches work, and Rust has good support for both mechanisms in the standard library. To choose between them, consider the following. Will threads mainly read data, mostly write data, or both? What are the access patterns? Avoiding deadlock is a primary concern for multi-threaded applications – nothing is worse than having a bunch of threads available to do work, and they are all stuck waiting for the other ones to get out of the way. How will deadlock be avoided? While over-engineering for performance is a common fault, having some idea of the performance requirements of your solution is essential. I’m a big fan of the rule: . Performance. keep the solution as simple as possible, but no simpler I decided on a shared state approach for the application I am creating. This decision also implied that my worker threads would work by polling – checking on things periodically instead of receiving an outside message. Here is what led me to that conclusion. I have three main threads. One is a web interface that allows for reading/writing of the shared state (get temperature, get thermostat setting, set thermostat setting). The web interface is, by definition, a creator of unscheduled activity – things come in based on an external client’s action and are not under the application’s control. Second, a pair of background worker threads react to the application’s environment. The first reads the temperature sensor, and the second calculates whether the thermostat should be set on or off and controls the physical relay to make that happen. The thermostat is in a separate thread, as it could turn on/off when the temperature crosses a threshold, or we receive a new thermostat setting from the web interface. I didn’t have to worry about contention with only three threads (assuming a single external client on the web interface). A simple shared state approach wouldn’t run into issues based on too many threads trying to access locks simultaneously. The logic for determining the thermostat’s state has a time component. We don’t want frequent, short bursts of on/off, which thrash the furnace. We enforce a minimum amount of time that the thermostat will be on or off before switching to another state. Accurately reacting to a message (the temperature reading or thermostat value changes) requires knowing how long it’s been since the thermostat changed. A shared state made sense based on these requirements. My design enforces a low thread count, so contention was not an issue (a common problem with shared state approaches). I need to keep track of time, so some state data was always required. Implementing two different state data mechanisms in the same application would be added complexity. With each thread doing its own thing and getting/setting shared state independently, we isolate each thread from the others. This choice led to a simpler overall application design. But, as I reviewed the Rust Book’s content on , the complexity of managing access from each thread seemed daunting. Plus, sprinkling thread-locking code in the application made it a mess – my nice single-purpose functions now had Mutex locking logic. Also, when accessing data through a Mutex lock dealing with Rust’s borrow checker across threads proved challenging. shared-state A simpler approach: To make this manageable, I used an approach I’ve used before on C++ projects – encapsulating the shared data into a separate class and pushing all Mutex logic into the class. Rust doesn’t have classes, but a couple of structs did the trick. To start, I created a struct to hold all the shared state data in a single place. Then I could deal with a single reference to this struct instead of managing each data element independently. pub struct SharedData {
    continue_background_tasks: bool,
    current_temp: f32,
    thermostat_value: usize,
    thermostat_on: bool,
    thermostat_change_datetime: OffsetDateTime,
} Then we define a struct that holds an Arc pointer – an Atomic Reference Count pointer to a Mutex that guards our shared data struct. We use this struct to control access to/from our shared data. pub struct AccessSharedData {
    pub sd: Arc<Mutex<SharedData>>,
} We will make many copies of this pointer – they all point to our Mutex, which is how we gain access to our shared memory space. We do this by customizing the Clone() method for AccessSharedData – it looks like the following. // Clone here makes a copy of the Arc pointer - not  the entire class of data
// All clones point to the same internal data
impl Clone for AccessSharedData {
    fn clone(&self) -> Self {
        AccessSharedData {
            sd: Arc::clone(&self.sd),
        }
    }
} To use this, we first create an instance of our SharedData struct (the simple .new() method isn’t shown above but is straightforward). let common_data = SharedData::new(
    true,
    configuration.initial_thermostat_value as f32 + 5.0,
    configuration.initial_thermostat_value,
    false,
    OffsetDateTime::UNIX_EPOCH,
); Then, we initialize an instance of AccessSharedData. // The wrapper around our shared data that gives it safe access across threads
let sd = AccessSharedData {
    sd: Arc::new(Mutex::new(common_data)),
}; We then give each thread we spawn() a cloned copy of the AccessSharedData struct. The clone call creates a copy of the Arc pointer, which we then move into the new thread. A similar method passes in a clone of the AccessSharedData struct to the actix_web HttpServer::new() method, so it is also available in HTTP client handlers. // Create another clone of our pointer to shared data, and send it into a new thread that continuously
// checks to see how the current temperature and current thermostat setting compare - and will
// trigger turning on the relay for the furnace as needed.
let sdc = sd.clone();
let control_handle = spawn( async move {
    tracing::debug ! ("kicking off control_thermostat");
    match run_control_thermostat( & sdc, configuration.poll_interval).await {
        Ok(_) => tracing::info ! ("control_thermostat ended"),
        Err(e) => tracing::error ! ("control_thermostat returned an error {:?}", e),
    }
}); Now that everyone has a copy of the Arc pointer, we need to create a means to use it to read/write our shared data struct. A simple set of getters/setters for each member of our struct handles the task of acquiring a lock, getting/setting the data, and automatically releasing the lock. By putting this logic surrounding the get/set and utilizing the end of the method as a scope boundary to force the lock to be released, we gain control over the access to our data. impl AccessSharedData {
    pub fn continue_background_tasks(&self) -> bool {
        let lock = self.sd.lock().unwrap();
        lock.continue_background_tasks
    }
    pub fn set_continue_background_tasks(&self, new_val: bool) {
        let mut lock = self.sd.lock().unwrap();
        lock.continue_background_tasks = new_val;
    }
    //repeated for remaining struct members
} When each get/set function returns, the lock is released. This approach also means it is impossible to deadlock around access to the structure – everything is locked and released immediately and prohibits anything else from getting in the way. With all of our locking mechanisms in place, using the shared data in the rest of our application is trivial. sd.set_current_temp(temp_f);
let temp_now = sd.current_temp();
let thermostat_now = sd.thermostat_value(); In Summary This strategy is encapsulation at its finest. Application code uses straightforward calls to methods to get/set the shared data elements whenever needed. Behind the scenes, we manage the Mutex’s locking for that access to be thread-safe and safe from deadlocks. And Rust’s borrow checker is extremely happy that we aren’t allowing direct shared mutable references to our shared data. If needed, you could easily extend this design pattern to implement a more robust access pattern. Putting locking logic inside getters/setters enables our shared data struct to hide the complexities of multi-threaded access – much like the standard library does for thread-safe collections. Using clones of an Arc makes it possible to acquire a handle to the shared memory struct in each thread. These two concepts are the core ideas that make our Easy Shared Data design pattern work. Also published here.

Implementing Multi-Threaded Shared Memory in Rust

The Radio Amateur's Hand Book, by A. Frederick Collins is part of . You can jump to any chapter in this book here: . Chapter XV: Operation  of Vacuum Tube Receptors HackerNoon’s Book Blog Post series [LINK TO TABLE OF LINK] XV. OPERATION OF VACUUM TUBE RECEPTORS From the foregoing chapters you have seen that the vacuum tube can be used either as a detector or an amplifier or as a generator of electric oscillations, as in the case of the heterodyne receiving set. To understand how a vacuum tube acts as a detector and as an amplifier you must first know what electrons are. The way in which the vacuum tube sets up sustained oscillations will be explained in in connection with the Operation of Vacuum Tube Transmitters. Chapter XVIII What Electrons Are.--Science teaches us that masses of matter are made up of molecules, that each of these is made up of atoms, and each of these, in turn, is made up of a central core of positive particles of electricity surrounded by negative particles of electricity as shown in the schematic diagram, Fig. 69. The little black circles inside the large circle represent positive particles of electricity and the little white circles outside of the large circle represent negative particles of electricity, or electrons as they are called. It is the number of positive particles of electricity an atom has that determines the kind of an element that is formed when enough atoms of the same kind are joined together to build it up. Thus hydrogen, which is the lightest known element, has one positive particle for its nucleus, while uranium, the heaviest element now known, has 92 positive particles. Now before leaving the atom please note that it is as much smaller than the diagram as the latter is smaller than our solar system. What Is Meant by Ionization.--A hydrogen atom is not only lighter but it is smaller than the atom of any other element while an electron is more than a thousand times smaller than the atom of which it is a part. Now as long as all of the electrons remain attached to the surface of an atom its positive and negative charges are equalized and it will, therefore, be neither positive nor negative, that is, it will be perfectly neutral. When, however, one or more of its electrons are separated from it, and there are several ways by which this can be done, the atom will show a positive charge and it is then called a positive ion. In other words a positive ion is an atom that has lost some of its negative electrons while a negative ion is one that has acquired some additional negative electrons. When a number of electrons are being constantly given by the atoms of an element, which let us suppose is a metal, and are being attracted to atoms of another element, which we will say is also a metal, a flow of electrons takes place between the two oppositely charged elements and form a current of negative electricity as represented by the arrows at A in Fig. 70. When a stream of electrons is flowing between two metal elements, as a filament and a plate in a vacuum tube detector, or an amplifier, they act as carriers for more negative electrons and these are supplied by a battery as we shall presently explain. It has always been customary for us to think of a current of electricity as flowing from the positive pole of a battery to the negative pole of it and hence we have called this the direction of the current. Since the electronic theory has been evolved it has been shown that the electrons, or negative charges of electricity, flow from the negative to the positive pole and that the ionized atoms, which are more positive than negative, flow in the opposite direction as shown at B. How Electrons are Separated from Atoms.--The next question that arises is how to make a metal throw off some of the electrons of the atoms of which it is formed. There are several ways that this can be done but in any event each atom must be given a good, hard blow. A simple way to do this is to heat a metal to incandescence when the atoms will bombard each other with terrific force and many of the electrons will be knocked off and thrown out into the surrounding space. But all, or nearly all, of them will return to the atoms from whence they came unless a means of some kind is employed to attract them to the atoms of some other element. This can be done by giving the latter piece of metal a positive charge. If now these two pieces of metal are placed in a bulb from which the air has been exhausted and the first piece of metal is heated to brilliancy while the second piece of metal is kept positively electrified then a stream of electrons will flow between them. Action of the Two Electrode Vacuum Tube.--Now in a vacuum tube detector a wire filament, like that of an incandescent lamp, is connected with a battery and this forms the hot element from which the electrons are thrown off, and a metal plate with a terminal wire secured to it is connected to the positive or carbon tap of a dry battery; now connect the negative or zinc tap of this with one end of a telephone receiver and the other end of this with the terminals of the filament as shown at A in Fig. 71. If now you heat the filament and hold the phone to your ear you can hear the current from the B battery flowing through the circuit. Since the electrons are negative charges of electricity they are not only thrown off by the hot wire but they are attracted by the positive charged metal plate and when enough electrons pass, or flow, from the hot wire to the plate they form a conducting path and so complete the circuit which includes the filament, the plate and the B or plate battery, when the current can then flow through it. As the number of electrons that are thrown off by the filament is not great and the voltage of the plate is not high the current that flows between the filament and the plate is always quite small. How the Two Electrode Tube Acts as a Detector.--As the action of a two electrode tube as a detector [Footnote: The three electrode vacuum tube has entirely taken the place of the two electrode type.] is simpler than that of the three electrode vacuum tube we shall describe it first. The two electrode vacuum tube was first made by Mr. Edison when he was working on the incandescent lamp but that it would serve as a detector of electric waves was discovered by Prof. Fleming, of Oxford University, London. As a matter of fact, it is not really a detector of electric waves, but it acts as: (1) a rectifier of the oscillations that are set up in the receiving circuits, that is, it changes them into pulsating direct currents so that they will flow through and affect a telephone receiver, and (2) it acts as a relay and the feeble received oscillating current controls the larger direct current from the B battery in very much the same way that a telegraph relay does. This latter relay action will be explained when we come to its operation as an amplifier. We have just learned that when the stream of electrons flow from the hot wire to the cold positive plate in the tube they form a conducting path through which the battery current can flow. Now when the electric oscillations surge through the closed oscillation circuit, which includes the secondary of the tuning coil, the variable condenser, the filament and the plate as shown at B in Fig. 71 the positive part of them passes through the tube easily while the negative part cannot get through, that is, the top, or positive, part of the wave-form remains intact while the lower, or negative, part is cut off as shown in the diagram at C. As the received oscillations are either broken up into wave trains of audio frequency by the telegraph transmitter or are modulated by a telephone transmitter they carry the larger impulses of the direct current from the B battery along with them and these flow through the headphones. This is the reason the vacuum tube amplifies as well as detects. How the Three Electrode Tube Acts as a Detector.--The vacuum tube as a detector has been made very much more sensitive by the use of a third electrode shown in Fig. 72. In this type of vacuum tube the third electrode, or grid, is placed between the filament and the plate and this controls the number of electrons flowing from the filament to the plate; in passing between these two electrodes they have to go through the holes formed by the grid wires. If now the grid is charged to a higher negative voltage than the filament the electrons will be stopped by the latter, see A, though some of them will go through to the plate because they travel at a high rate of speed. The higher the negative charge on the grid the smaller will be the number of electrons that will reach the plate and, of course, the smaller will be the amount of current that will flow through the tube and the headphones from the B battery. On the other hand if the grid is charged positively, see B, then more electrons will strike the plate than when the grid is not used or when it is negatively charged. But when the three electrode tube is used as a detector the oscillations set up in the circuits change the grid alternately from negative to positive as shown at C and hence the voltage of the B battery current that is allowed to flow through the detector from the plate to the filament rises and falls in unison with the voltage of the oscillating currents. The way the positive and negative voltages of the oscillations which are set up by the incoming waves, energize the grid; how the oscillator tube clips off the negative parts of them, and, finally, how these carry the battery current through the tube are shown graphically by the curves at D. How the Vacuum Tube Acts as an Amplifier.--If you connect up the filament and the plate of a three electrode tube with the batteries and do not connect in the grid, you will find that the electrons which are thrown off by the filament will not get farther than the grid regardless of how high the voltage is that you apply to the plate. This is due to the fact that a large number of electrons which are thrown off by the filament strike the grid and give it a negative charge, and consequently, they cannot get any farther. Since the electrons do not reach the plate the current from the B battery cannot flow between it and the filament. Now with a properly designed amplifier tube a very small negative voltage on the grid will keep a very large positive voltage on the plate from sending a current through the tube, and oppositely, a very small positive voltage on the grid will let a very large plate current flow through the tube; this being true it follows that any small variation of the voltage from positive to negative on the grid and the other way about will vary a large current flowing from the plate to the filament. In the Morse telegraph the relay permits the small current that is received from the distant sending station to energize a pair of magnets, and these draw an armature toward them and close a second circuit when a large current from a local battery is available for working the sounder. The amplifier tube is a variable relay in that the feeble currents set up by the incoming waves constantly and proportionately vary a large current that flows through the headphones. This then is the principle on which the amplifying tube works. The Operation of a Simple Vacuum Tube Receiving Set.--The way a simple vacuum tube detector receiving set works is like this: when the filament is heated to brilliancy it gives off electrons as previously described. Now when the electric waves impinge on the aerial wire they set up oscillations in it and these surge through the primary coil of the loose coupled tuning coil, a diagram of which is shown at B in Fig. 41. The energy of these oscillations sets up oscillations of the same frequency in the secondary coil and these high frequency currents whose voltage is first positive and then negative, surge in the closed circuit which includes the secondary coil and the variable condenser. At the same time the alternating positive and negative voltage of the oscillating currents is impressed on the grid; at each change from + to - and back again it allows the electrons to strike the plate and then shuts them off; as the electrons form the conducting path between the filament and the plate the larger direct current from the B battery is permitted to flow through the detector tube and the headphones. Operation of a Regenerative Vacuum Tube Receiving Set.--By feeding back the pulsating direct current from the B battery through the tickler coil it sets up other and stronger oscillations in the secondary of the tuning coil when these act on the detector tube and increase its sensitiveness to a remarkable extent. The regenerative, or feed back, action of the receiving circuits used will be easily understood by referring back to B in Fig. 47. When the waves set up oscillations in the primary of the tuning coil the energy of them produces like oscillations in the closed circuit which includes the secondary coil and the condenser; the alternating positive and negative voltages of these are impressed on the grid and these, as we have seen before, cause similar variations of the direct current from the B battery which acts on the plate and which flows between the latter and the filament. This varying direct current, however, is made to flow back through the third, or tickler coil of the tuning coil and sets up in the secondary coil and circuits other and larger oscillating currents and these augment the action of the oscillations produced by the incoming waves. These extra and larger currents which are the result of the feedback then act on the grid and cause still larger variations of the current in the plate voltage and hence of the current of the B battery that flows through the detector and the headphones. At the same time the tube keeps on responding to the feeble electric oscillations set up in the circuits by the incoming waves. This regenerative action of the battery current augments the original oscillations many times and hence produce sounds in the headphones that are many times greater than where the vacuum tube detector alone is used. Operation of Autodyne and Heterodyne Receiving Sets.--On page 109 [Chapter VII] we discussed and at A in Fig. 36 is shown a picture of two tuning forks mounted on sounding boxes to illustrate the principle of electrical tuning. When a pair of these forks are made to vibrate exactly the same number of times per second there will be a condensation of the air between them and the sound waves that are sent out will be augmented. But if you adjust one of the forks so that it will vibrate 256 times a second and the other fork so that it will vibrate 260 times a second then there will be a phase difference between the two sets of waves and the latter will augment each other 4 times every second and you will hear these rising and falling sounds as beats. Now electric oscillations set up in two circuits that are coupled together act in exactly the same way as sound waves produced by two tuning forks that are close to each other. Since this is true if you tune one of the closed circuits so that the oscillations in it will have a frequency of a 1,000,000 and tune the other circuit so that the oscillations in it have a frequency of 1,001,000 a second then the oscillations will augment each other 1,000 times every second. As these rising and falling currents act on the pulsating currents from the B battery which flow through the detector tube and the headphones you will hear them as beats. A graphic representation of the oscillating currents set up by the incoming waves, those produced by the heterodyne oscillator and the beats they form is shown in Fig. 73. To produce these beats a receptor can use: (1) a single vacuum tube for setting up oscillations of both frequencies when it is called an autodyne, or self-heterodyne receptor, or (2) a separate vacuum tube for setting up the oscillations for the second circuit when it is called a heterodyne receptor. The Autodyne, or Self-Heterodyne Receiving Set.--Where only one vacuum tube is used for producing both frequencies you need only a regenerative, or feed-back receptor; then you can tune the aerial wire system to the incoming waves and tune the closed circuit of the secondary coil so that it will be out of step with the former by 1,000 oscillations per second, more or less, the exact number does not matter in the least. From this you will see that any regenerative set can be used for autodyne, or self-heterodyne, reception. The Separate Heterodyne Receiving Set.--The better way, however, is to use a separate vacuum tube for setting up the heterodyne oscillations. The latter then act on the oscillations that are produced by the incoming waves and which energize the grid of the detector tube. Note that the vacuum tube used for producing the heterodyne oscillations is a generator of electric oscillations; the latter are impressed on the detector circuits through the variable coupling, the secondary of which is in series with the aerial wire as shown in Fig. 74. The way in which the tube acts as a generator of oscillations will be told in . Chapter XVIII About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Collins, A. Frederick. 2002. The Radio Amateur's Hand Book. Urbana, Illinois: Project Gutenberg. Retrieved April 2022, from https://www.gutenberg.org/files/6934/6934-h/6934-h.htm#chap15 This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever.  You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

The Operation  of Vacuum Tube Receptors

I recently stepped away from the full-time work rat race and found myself with some time on my hands. Being a life-long technologist, I naturally started looking into what new things have come along that I didn’t have time for when consumed by a full-time job. popped up on a short list of new technologies that looked interesting. I started programming in C/C++ on DOS/Windows/Mac/Unix many moons ago – so a new statically typed compiled language heralded as the “new C/C++” was a natural choice. Going through the , I absorbed the concepts pretty quickly – but found myself in that “what next” stage. This is always the most challenging stage when learning new technology – you understand the basics but don’t know where to start to build something “real.” Rust Rust Book In search of a solution to this problem, I ran across an excellent book by Luca Palmieri: . The book walks through the building of a non-trivial, production-quality web application in Rust. Many useful concepts are built out and illustrated, including: Zero to Production in Rust Building a production-quality web server application in Rust. Telemetry – getting traces/logs distributed to a central location and managing error handling across several different API stacks. Implementing end-user authentication – production-grade user authentication, including encryption and protection from common hacking methods. SQL interaction – Postgres, in this case, including migrations. External API usage – calling external REST-based services. HTML templates – producing web pages for end-user interaction from a server. Session management – Redis in this case, but a strategy for keeping track of end-user state. After working through the book, I felt I had a decent handle on how this stuff works. As a bonus, I haven’t done a lot of production-level web server development in other languages – and seeing the normal challenges in this environment solved was interesting. But I’ve never claimed to be proficient in a tool until I’ve used it to build something. About this time, an outside inspiration popped up – I wanted a way to control a thermostat in a detached workshop remotely. The heater for my workshop is a simple 2-wire control – not nearly as complicated as a home furnace. A is overkill, I’ve done some programming for Arduino and Raspberry Pi devices in the past, so this project was born. Google Nest In laying out the architecture for my new project, I decided on the following initial scope: I’m only worried about heating – so a single control and simplified logic for either turning on the heat or turning it off. For the main control platform, the Raspberry Pi is an easy choice. It runs a Unix OS, has Wi-Fi networking support, and has easy access to the physical devices needed for temperature measurement and relays to work as a thermostat. I would use Rust as the development language and take advantage of the following Rust features: Cross-compile to a native executable (ARM processor). Use the Actix-Web framework to expose REST interfaces for remotely setting the thermostat and retrieving the current temperature. Utilize the Tokio run time for a multi-threaded application that can read temperatures, decide whether to turn the thermostat on or off, receive commands to set the thermostat, and send data externally. Gain programmatic access to physical devices on the Raspberry Pi for reading temperature and controlling a relay to turn the heater on or off. I wanted external visibility into how the thermostat was working. I decided to push data to the cloud instead of keeping it on the device so that an external “watcher” can send an alarm if something isn’t working correctly. I wouldn’t want a thermostat not to turn on when it’s supposed to (freezing things is bad) or stay on too long (100 degrees is also bad and a potential fire hazard). I chose a REST interface for controlling the thermostat – making it easy to connect something to it later. I might make a Flutter app for my phone (more new things to figure out!) or a web interface. I chose to address security through physical network access and firewalls and not implement a security layer on the API. I am saving implementing security for the 2.0 version, which keeps the initial development cleaner and easier. I would follow the main principles from Zero to Production in organizing the project and utilize many of the same external Rust packages. I liked the coding style and choices made in the book and consider it a best practices reference. I intended this to be a hobby project – not a commercial production-ready implementation. When I install this for actual use, I will have a backup system to ensure nothing bad happens. Things work in the project’s current state – but I don’t profess to have the system hardened. More testing is needed before I’ll trust this with anything important. The following diagram depicts the system architecture for the solution: The subsystems of the application are as follows: – This holds the current state of the application and is accessed from the other subsystems as needed. Each subsystem runs on independent threads, so we wrap the shared data to protect it when multiple threads try to read/set its data independently. Shared Data – We run an actix-web server, allowing for multiple HTTP clients. This interface allows external access to the thermostat – giving it the “wireless” functionality we desire. These interfaces enable setting the thermostat value (the desired minimum temperature) and retrieving the current temperature and thermostat setting. Web (HTTP) Interface – An independent thread polls the temperature sensor periodically. Each time it reads a temperature value, it changes the internal state and then pushes those values to the external cloud storage. Read Current Temperature – Another independent thread polls the Shared Data to see if the thermostat should be on or off. When the temperature is below the thermostat value, the external control relay is set on – else, it is set off. A minimum time on/off threshold avoids thrashing, so we store the control relay change time in the Shared Data, which becomes part of the logic for determining the relay state. Set Thermostat – All tracing and error messages are funneled through a Telemetry layer and pushed to an external collector for visibility. Telemetry – We’re using AWS as our cloud provider and utilizing a Lambda function (written in Rust!) to receive HTTP messages from the application and store them in a DynamoDB table for external processing. The cloud database is our repository of historical information on how the temperature and thermostat settings have changed over time. Eventually, a monitor against this data will alert us if something goes wrong. Cloud Data Storage – We need a way to control the thermostat and see its current state. This UI interacts with the application via HTTP to get/set data. It also can retrieve historical data from the cloud for display. End-User UI The GitHub link for the source code is . I’m still fiddling with things and working on a GUI client. I plan on diving into the details of the application in a series of follow-on posts – stay tuned! here

Raspberry Pi Wireless Thermostat - in Rust!

What to Choose: Dating Script or Custom Dating Software? With the rise of digitization and more people adopting a remote lifestyle, it is safe to claim that online dating platforms are here to stay! Have you also decided to tap into this ever-evolving niche? If so, it is crucial to focus on the overall development of the website and a mobile application. To start with, you can either use a ready-made dating script or go all out and build custom dating software from scratch, just like Tinder did! The answer to this dilemma will depend on your business model's demands and the number of resources at hand. This article will discuss out-of-the-box and custom dating solutions and their pros and cons in detail. Additionally, we aim to clear all the doubts and help you figure out the right choice for the business. Keep on reading to know more! What is a Dating Script? Dating scripts define the expected date behavior pattern used to craft an algorithm to match people based on compatibility. These ready-made solutions use numerous search filters like gender, distance, or age to help users find suitable partners. Additionally, such software allows better profile management and social media account integrations. Ready-made dating scripts work on a subscription model where you can gain rights to the service on a 100% prepayment basis. As such, the contract can be canceled as per your requirements whenever required. Who Uses Ready-made Dating Software? Most users of ready-made dating software are individuals looking to step into the online dating domain within no time. Such entrepreneurs want to launch their dating websites or mobile applications but don't have enough capital to hire a development team. Therefore, they purchase a pre-built framework that best fits the . Ready-made solutions work best for small or medium-sized enterprises aiming to achieve satisfactory results within a strict budget. business requirements to scale quickly Advantages and Disadvantages of Using a Dating Script Ready-made dating software is a preferred development path for early-stage business organizations. You get the required services at an affordable price at the risk of sacrificing some detailed, personalized features. Here are a few pros and cons to note: Pros Some notable qualities in favor of out-of-the-box solutions are as follows: Ready-to-use Software with Rapid Implementation Can't wait for months or a year to launch your new business idea? If so, ready-made dating solutions fit the bill perfectly. You get a chance to enter the market relatively quickly and 'strike while the iron's hot.' As such, there's no worrying about competitors reaching and acquiring the target audience first. With SkaDate, you can tap into the dating industry at your convenience and grab a piece of the market share with fewer competing organizations. After all, markets work on a 'first come, first serve' basis. You Benefit From Experts' Knowledge Base One of the most significant benefits of using off-the-shelf dating software is the deep knowledge base that comes with it. You don't have to worry about setting up the proper interface or picking the precise features required by your future clients. Instead, experts have already conducted sufficient research and added different elements like multiple registrations, instant notifications, smooth search filters, etc. As a result, these pre-built dating solutions save you a lot of time, headaches, and service costs. Additionally, since the experts thoroughly test and approve the prototype, there are minimal chances of facing an error. If some integrations don't fit your system well, you can always contact the service professionals at the back end to solve the problem at hand. Highly Efficient and Value for Money Did you know that building a proper quality dating application can take nearly 1000 hours? , that's almost half a year of efficient working. If you want something quicker, ready-made dating software can help you forgo all these hours and directly skip to the pre-launch stage. In terms of 40 hours per week As such, you no longer have to consider high development charges and additional expenses that come along. Here, you don't have to worry about any maintenance or service charges imposed. Cons Ready-made solutions don't always fit your business requirements. Here are a few reasons why: All Desired Features are not Present If you have dreamed of framing your dating website or mobile application in a specific way with unique features, ready-made dating solutions aren't favorable. Here, you must make do with the available operations and features. Vendors update the system from their end only at specific intervals. Additionally, your product features are limited till the selected tariff plan. That being said, ready-made dating solutions are not what they used to be and can provide you with custom development features. As such, you can now look for specific organizations that offer the option of adding certain features later on. You Don't Choose the Framework For most clients looking to start their online dating business, the framework is of minimal relevance. However, the developers or web designers working on the final project might prefer to work in a particular framework they are fluent in. If not, they might face some trouble integrating the purchased software. In ready-made platforms, you have no say in the type of framework. The developer from the service-providing company picks it from their end. However, most entrepreneurs can comfortably work with such solutions as long as flexibility and scalability are not compromised. Must Work with Ready-made Back-end Management This point is not necessarily a con, but something business entrepreneurs should definitely note while making the final decision for their application-building process. Ready-made solutions provide multiple features that you can manage according to the guidelines present in the selected package. For example, the content moderation system will be built on a specific workflow that developers decide. While you're bound to adopt the same workflow, there is a particular benefit to it as well. Here, the back-end operations are custom-made for an online dating space and will allow you to manage the working process well. What is Custom-made Dating Software? Custom-made dating software is a product specifically designed to keep client guidelines in mind. As such, these solutions completely match your requirements and can be used to create the website or mobile application accordingly. You can hire an external development team and relay all your requirements to them or work with an internal IT team. The latter option will offer you more flexibility and enable quick edits and feature additions whenever required. Who Uses Custom-made Dating Software? Here, the main question is not about who wants to use it but who can afford it. Primarily, this subset includes large-scale business enterprises looking to tap into a different niche. Small or medium-sized organizations can also look into custom-designed software if they can source the right talent at low prices. In general, it is safe to say that well-established companies looking to start online dating services as a side business can also fall into this category. In such cases, entrepreneurs are already connected with a development team and can start the project quicker. Advantages and Disadvantages of Using a Custom-made Dating Software Bespoke or custom-made software is ideal for people with unique ideas waiting to launch their businesses. Here, the client often has enough money to hire a development team and does not want quantity over quality. Pros Plenty of successful business owners in the past have used custom-made solutions. They offer distinguished benefits like: Customized as per Your Needs A custom-made dating solution defines all the required features and is ideal for the personalization of a business. Investing money in such products will make you realize that certain features are available solely to your business. No one will have previously experienced finding the right dating partner with your specific features on other applications. For example, if you want to add a new feature or search filter, you can easily do so without replicating other business organizations. Smooth Integration or Flexibility While working with a dating script, you might face certain challenges related to product integrations. It happens because those solutions are built on a specific framework incompatible with your website or application. However, with custom-made products, your development team has the complete freedom to work in the framework they find most compatible. Additionally, you can change the interface or outlook of the product whenever required without any hassles. Improved Data Safety With Minimum Limitations When you opt for a ready-made solution, you have to compromise on features as well as scalability. For example, imagine your business takes off pretty well. Now, you need to upgrade your site or application to handle more users urgently. To do so, you will have to opt for a different tariff plan. However, with custom dating software, no such limitations are imposed. You can scale continuously and upgrade the platform as the need arises. Additionally, your data will remain completely safe as no other business owners or third-party members will be able to access it remotely. Cons Even though personalized dating software seems to be the best option in the market, you must also note the following disadvantages: Total Expenditure Incurred is High With the amount of money spent on a quality development team for almost six months, it is possible to launch other successful businesses. You might have to pay between to build a dating application like Tinder. It might be cheaper if you are hiring a team that creates dating apps based on the . Additionally, you must churn out maintenance and licensing fees to approve all the products beforehand. $40,000 and $45,000 ready-made script Doing so will almost eat up the entire budget of an entrepreneur looking to establish a strong position in the online dating industry. On the other hand, working with ready-made systems like SkaDate will cost you a one-time fee of $999 for a basic package. You can then invest the saved money in different domains like advertising or sales. Product Development is Time Consuming When you go down the custom development path, you will realize that there are a lot of challenges or hurdles to be crossed. Product development usually has a complete lifecycle, including various stages like planning, analysis, design, implementation, testing & integration, and maintenance. Skipping any step can have negative impacts on the entire project. As such, the whole operation takes plenty of time. Therefore, it is safe to say that custom-made development is not ideal for people looking to enter the market relatively quickly. You Have to Spend Additional Resources For custom-made dating software development, you will either outsource the work via an external IT team or hire in-house talent. Most people prefer to opt for the latter option due to better results. However, in such situations, you have to hire a complete department and lead the team regularly. The company must pay regular salaries and maintain a good work culture in the office. You must also spend extra resources on employee insurance, house rent allowance, etc. You spend more money, energy, and time in the long run. Verdict: Is Custom Dating Software or a Ready-Made Solution Better? On examining both options closely, it is appropriate to say that the correct answer depends on your final budget and timeline. Based on the type of package chosen, you can avail different benefits and build a solid, professional dating site. Doing so will also allow businesses to launch a mobile application simultaneously without any additional costs or complications. Also Published here

Building a Dating App: To Code From Scratch or Use a Script?

A great deal of hype surrounds the impending launch of Apple’s Private Relay, a browser-based encryption boost that is set to be offered as a “public beta” to iCloud+ subscribers this fall. Current iCloud subscribers will automatically be upgraded to iCloud+ at no charge. Private Relay will automatically be downloaded to iPhones or other Apple iCloud-enabled devices and will become available on forthcoming iOS and MacOS devices. While more is unknown than is known about Apple’s newest addition, many non-technical users of Apple products might breathe a collective sigh of relief that Apple seems to be doing everything they can to add greater privacy in a world that seems less than secure. The Advantages of Private Relay If Apple’s implementation of this new feature actually lives up to its lofty promises, then Private Relay will offer a high level of privacy, both on the provider side and on the user side. Private Relay is designed to encrypt all information about the user, such as who you are, where you are, and what websites you visit. They’re planning to do such a thorough job of this that even Apple won’t know who you are. This is unlike traditional Virtual Private Network (VPN) providers, which typically have this information. VPNs first became available for web users more than twenty years ago, and many savvy Internet browsers use them to hide their IP address. VPNs have long allowed people to ward off hackers, keep their identity totally private, and even watch Netflix movies in countries that have banned certain content. Lately, companies have also gotten on the privacy bandwagon—especially post-pandemic, when many of their employees have been working remotely from home. Private Relay, although not technically a VPN, seems to be Apple’s way of getting in on the trend toward greater privacy. The real advantage of Private Relay is that it will have a very simple interface that is understandable enough for even a general, non-techie audience. Since it is built right into the operating system for iCloud+ subscribers, Apple customers will trust it to keep them safe and secure while browsing. Also, it may very well work better than a third-party VPN application used on Apple and may not slow down the speed of your connection like VPNs sometimes can. Last, it’s free for iCloud+ users. The Disadvantages of Private Relay From a strategic perspective, Private Relay, at least in its first iteration, won’t be totally effective for all users. First of all, this feature allows you to choose your general IP address or simply choose an IP address somewhere in your country and/or time zone. Because of this, Private Relay will not allow you to geo-hop, meaning the service still uses your approximate existing geographic location, making it more impossible to do things like stream Netflix content from a different country. Apple has a vested interest in working cooperatively with content providers and has no desire to estrange them by infringing on the regional blocking schemes already in place. Also, since there is no change of region, and Apple will transfer the information about the user’s region to the website, advertisers will still be able to target a user based on their location. Secondly, this feature will not be available in all countries. Apple has already announced that they will comply with local regulations and so will be unable to offer Private Relay in China, Belarus, Colombia, Egypt, Kazakhstan, Saudi Arabia, South Africa, Turkmenistan, Uganda, the Philippines, and Russia. Third, even though Apple execs have been depicting Private Relay to be a plausible runner-up to commercial VPNs, it is not in fact a VPN and thus has diminished functionality. For instance, this encryption boost will only perform the function of privacy and anonymity. Other functions are not clear, and we don’t yet know exactly how this interface will work. Because of this, users who want to rely on Private Relay as though it’s a true VPN might be opening themselves up to risk. In addition, there will be almost no settings for users to choose from. That is, it will be almost impossible to adjust the specific condition of how Private Relay works for individual users and their needs. Time will tell what risks might occur from this initial set-up, and not all cases will be tested immediately and will need to be fixed gradually. Fourth, Private Relay will only be available for Safari users, so those who use Chrome or Firefox will be unprotected. This means Private Relay is not a one-stop-shopping solution for privacy and does not encrypt data across all apps on your device. Many people might not realize this and think they are more fully protected than they actually are. In addition, this service is only available for those with iCloud subscriptions. Yet another disadvantage of this encryption service is that Apple surely knows everything about its users. Since many users are worried about privacy and staying anonymous online, many commercial VPN providers solve this problem by not physically storing logs. If Apple does store information about its users, then what happens if the government asks for information about customers? Does Apple need to provide this data? Will Private Relay Kill the VPN Market? From my standpoint as the founder and CEO of a company that focuses on privacy, security, and safety, I believe that Apple’s Private Relay will not kill the VPN market, but it could affect some of the market players and will surely create more competition. Although this feature can provide some anonymity for users, and should be easy enough to turn on and off, making you anonymous/not anonymous, it still will be unusable in countries where privacy is most at risk (like China). In such cases, VPNs will remain the most effective solution. Also, since the service is so new, and a lot is unknown about how it will work, we can’t yet be sure about the level of anonymity promised to Apple’s customers. As such, the VPN providers still wear the pants in the privacy household. Private Relay will not be a negative addition to Apple’s features and might prove helpful for those not particularly tech savvy. However, those who want fuller protection might want to combine this service with a traditional VPN. The Future for VPN Providers Now That Apple Is In the Game Apple’s release of this built-in virtual private network might trigger some companies—like tech behemoth Cisco, for instance—to release a full security system. Other OS vendors could also think to get into the game, creating similar systems for themselves. If other companies begin offering their versions of security services, then current VPN providers will face greater competition in the years ahead. In general, however, Private Relay should not hurt the VPN industry that drastically. For those who truly need a VPN, the set of features offered by Apple’s new offering will not be enough. Also, there’s bound to be some overlap in emerging technologies. For instance, storing passwords for browsers did not hurt the market caps of top password management companies, even though almost all browsers have this option now.

How Apple’s Upcoming Private Relay Feature Will Affect End Users and The VPN Market

Ethereum 1.0 was a landmark moment in blockchain technology. Allowing for the trustless execution of code on a blockchain in its current form, however, it does not have the ability to scale to the level of computation that would be needed to disrupt current financial systems. With the evolution of Ethereum 2.0, it will usher in the new era of . "Broadband Blockchain" As part of this upgrade, Ethereum is changing some of the most foundational components of its system, most notably, its consensus algorithm. A consensus algorithm is the mechanism used to come to agreement on the state of the blockchain. Ethereum 1.0 uses the now famous Proof of Work (or Nakamoto) consensus mechanism. This method is extremely energy intensive, with Bitcoin and Ethereum together consuming more energy coming to consensus than the entire annual .  Ethereum 2.0 will instead use Proof of Stake consensus.In simple terms, if PoW consensus is a guessing game trying to find a magic number, PoS consensus is an organised voting system where everyone keeps a large sum of money in escrow, and if they misbehave, some of their escrowed money is taken off of them (called slashing). energy consumption of Switzerland The users that take part in this proof of stake system are called stakers, and they lock up 32 ether into the escrow contract and deploy small servers on the internet called validators to perform the duties of a staker in exchange for rewards. The rewards vary depending on the number of people taking part, but roughly vary between the margins of 2% to 18% APR. Ethereum 2.0 had its Genesis block on December 1st 2020. At launch there was more than $400m worth of Ether locked into this escrow, and there were 21,063 validators in operation, each communicating with each other through beacon nodes using peer to peer communication across the internet. The infrastructure to run all of these validators is immense, and the security and reliability of these systems is of utmost importance, as any downtime results in a loss of earnings or even a loss of the principal sum escrowed. Blockdaemon has been developing secure and scalable non-custodial Eth2 Staking Infrastructure for its enterprise clients, and today we're sharing a few pro tips to maximise the safety and performance of your enterprise-grade staking infrastructure. Let clients control their withdrawal key By default, each of the Eth2 clients (Prysm, Lighthouse, Teku, Nimbus etc.) create withdrawal keys and validating keys from the same mnemonic phrase. This is the easiest way to get started, but if you are building an enterprise staking solution for customers, this means you are taking full custody of their funds. This has major security and legal implications. Instead, have your clients create an Eth2 address they control, and use a tool like to craft a custom deposit data file that allows your enterprise's validator to withdraw to the client's withdrawal address. This way, if your validating server is compromised, the attacker can force you to exit the validator (with or without getting slashed in the process), but the exited funds will be sent to your client's cold wallet, which the attacker should not be able to access because it should be nowhere near your compromised validator--thus limiting potential damage. If an attacker can only burn your client's funds, but cannot steal them, they are less incentivised to attack your validating stack relative to other custodial enterprise staking solutions. ethdo Have robust monitoring and alerting for your validator If your validator goes offline, how long would it take you to notice? Make sure to invest in monitoring infrastructure that can watch your validator's participation in the network, as well as some of the more general server management risks like running out of free disk space on your device, your CPU getting overloaded, your server clock falling out of sync or your validator running out of free memory to use. It is important to remember that monitoring without alerting is not sufficient. If you have to actively check your monitoring to know if there is an issue, you are likely to get complacent as the months go by, and sooner or later you could miss a long period of inactivity that would have been avoidable had you integrated prometheus or or any of a number of alerting tools into your enterprise stack. alert-manager opsgenie Consider remote key signers As of writing this post, the , and clients all have the ability to integrate with remote key signing infrastructure. These services store your private keys in an encrypted and secure fashion, and make it even more difficult for a hacker to extract your precious private keys. is an enterprise solution from for fault tolerant and secure key management of Eth2 validating keys that might make your enterprise staking solution more robust. Prysm Lighthouse Teku Dirk Attestant Defend yourself against DoS attacks with Sentry Nodes Currently, a significant concern when it comes to Eth2 staking is that it is relatively trivial to correlate validators to the IP address of the beacon node they attach to. Although the validators themselves should not be exposed to the internet, their beacon nodes are, and with this knowledge, it becomes feasible to selectively DoS the beacon node that owns a validator that's about to propose a new block. This means a malicious attacker can prevent your validator from doing its duties by overloading the beacon node it's attached to for about 12 seconds every 6 minutes when your validator is due to make an attestation or block proposal. To mitigate this issue, one can design an array of publicly accessible beacon nodes that act as sentries, and the beacon node your validators attach to is not publicly accessible over the internet and instead it peers with only your sentry nodes. This means an attacker needs to simultaneously DoS every one of these nodes to keep your validator offline, otherwise one of them will be able to relay your validators attestations to the wider network successfully. Be client agnostic In August 2020, a bug in the Prysm client's clock management code caused every Prysm client to go offline, resulting in more than 60% of the Medalla testnet validators going offline. This problem was exacerbated when an emergency release to solve the problem was broken, rendering the prysm validators unusable on that version, requiring a downgrade to rectify. In an emergency situation where a specific client becomes unusable, it helps tremendously to be able to run your staking system using more than one of the clients. Interoperability of clients is a strong priority amongst the Eth2 teams, and through their hard work it is becoming achievable to be able to replace a Prysm validator with a Teku validator, or a Lighthouse validator seamlessly. With multiple supported client implementations, your company, and your users, are more protected than if your entire infrastructure relies on just one Ethereum 2.0 client. Practice, practice, practice No system is fully reliable, no system has 0 downtime forever. Don't be afraid to break your testnet systems so that you can work on your recovery skills. Make it fun, make a red team and blue team out of your engineers and incentivise them to break their own infrastructure. Develop playbooks for handling the different types of faults so when they happen in production people immediately know how to remedy the situation. Build experience and confidence in your team that they can successfully manage this brand new infrastructure in a brand new threat landscape. Mistakes happen, but not learning from your mistakes is probably the worst one of all. To learn more about how you can participate in Ethereum 2.0 with us, visit our for more information. marketplace By Oisin Kyne, Developer at Blockdaemon

How To Build A Secure Eth2 Staking Infrastructure

(This article is co-authored by ) Chinedu Imoh Our friend had a damaged fan — the fan’s control board got fried. We were tired of seeing it lie around the house when we visit her on weekends but recycling electronics in Nigeria is not a thing. We thought, instead of harming the world by throwing the fan away, we could just pull out the damaged board, join the wires under the hood manually and still have the fan work. ( ) Alt : Type of fan used for article demo With a flat screw driver, as seen in the picture on the right, we pulled out the control panel of the board and cut out the wire from the board. ( ) Alt : Pulled out control chip (the actual damaged fan is a black one — we got a white one that’s good At this point joining a couple of wires would get the fan back to live but it’s the era of IoT and we thought to ourselves — “this is a free fan we could play with, what can we do?” Well it didn’t take us too long to REALIZE that with a Tessel 2 and a relay, we cloud turn this so-called damaged fan into one of the smartest device in our friend’s home. This article outlines our journey to how we made this fan smart. At the end, you will learn: What requirements we used to make this fan smart How we used a relay to interface this fan with a Tessel IoT board How we controlled this fan with a computer (can be a phone) through a Tessel board The best way to follow this article is to get the same devices we used but of course you might not have that luxury. This is why we are structuring this post in a way that you can apply what ever you learn in your IoT journey — regardless of whether: This is your first look at IoT You have been doing IoT stuff but want to learn how to control home appliances with IoT Requirements This upcoming list does not have to be followed religiously and you can replace each part with what ever works best for you: A room fan — we are using Honeywell QuietSet Fan IoT Board Tessel 2 Saint Smart Relay Jumper cables Basic knowledge of JavaScript/Node You can buy a Tessel kit which comes with Tessel 2, cables, few sensors, etc. The relay and fan does not come with the kit but you can get those from the links. Circuit Diagram We are totally aware that this article targets both developers as well as electrical engineers. With this in mind, we chose to not draw a professional circuit diagram but a simpler flow diagram of what the connections look like. The secondary reason for not making a professional circuit diagram is because we both have computer programming background and suck terribly at such. ( ) Alt : Circuit diagram The only thing you should care about are the wires we pulled out of the control chip. That said, feel free to skip the next section if you don’t want to understand where those wires poking out of the fan came from. How the fan works The components that make up the mechanics of the fan are: A big fan motor A capacitor A small fan motor(for swing/rotation) Power source The big fan motor has five multicoloured wire’s — two (green) are connected to the capacitor, the next two (yellow and red) are connected to the chip (which we pulled out), and the last one(white) is connected to the smaller motor which in turn also goes to the board. Capacitors are devices which store electrical charge, a motor capacitor, such as a dual run capacitor is an electrical capacitor that alters the current to one or more windings of a single phase AC induction motor to create a rotating magnetic field. In this case both(green) wires of the capacitor are connected to the big fan motor to run both motors. The small fan motor is used to rotate the body of the fan so as to distribute air to the room. Both blue and black of the small fan motor wires are taken the board, but the blue is first connected to the big fan before getting connected to the board. The 2 power source (140V wire’s) both go straight to the board. In summary with regard to the wires we pulled out, the white and the the blue are used by the relay to toggle the fan while the black and yellow are used to toggle the swing. The remaining two wires (red and brown) can be used to toggle both power and swing at once. Setting up Tessel 2 Install the Tessel 2 node module using the following command: npm install -g t2-cli Plug in the Tessel to your computer using the provided USB cable. You can refer to the following image to see how this connection should be made: ( ) Alt : Connecting Tessel to a computer It takes to finish booting — at this stage a light will blink until booting is completed. After the Tessel is done booting, run the following command to find it: 30 seconds t2 list You should see a message like the one below: Searching nearby Tessels .
  USB Tessel-AF768F095 INFO for .. means it’s connected via USB. You can connect via wifi which we will see soon. USB is the name of the Tessel. You can choose to rename it with: Tessel-AF768F095 t2 rename <name> Where is the new name. Running again will list the Tessel but with its new name: <name> t2 list Searching nearby Tessels .
  USB HomeFan INFO for .. Connect Tessel to Wifi Connecting to wifi is pretty straightforward — with the Tessel still connected to your computer, run the following command: t2 wifi -n <network-name> -p <password> is the wifi SSID or network name <network-name> is the wifi password <password> We have tried connecting to a hotel wifi and it didn’t work. If that’s the kind of network you are on, I am not sure you will have the best luck connecting. You can choose to push your JS code to Tessel using wifi instead of USB. To set that up, run the following command: provision t2 With that in place, you can run again to confirm wifi is authorized. You see the following: t2 list Searching nearby Tessels .
        HomeFan HomeFan        USB INFO for .. LAN Board connections If you can join legos, you can totally do this kind of connections. SAFETY WARNING — PLEASE READ Before you move on, I would like to warn you that the relay is a high voltage device. Once connected to the fan and the fan is powered, there are chances of being electrocuted if you skin gets in contact. Tessel 2 ←→ Relay Before we move on with any connection, this is what a Tessel 2 board and our Relay looks like: ( ) Alt : Tessel 2 and Saint Smart Relay A note on both… The is the CPU of our setup. This is what we will ship JavaScript to setup a network access point, control the I/O devices (eg the relay) etc. Basically, this is the board that replaces the chip we pulled out earlier. Tessel The black rectangle plunging out of the board (picture coming soon below) is where you connect your input and output devices. This is where we will connect the relay to. You can also connect sensors, displays, and other accessories using this port. The saint smart 4 pin module is a separate hardware device that takes instruction from a 5v chip, for example Tessel 2, and uses the instruction to control high voltage devices of up to 240v (eg. fan). With out the relay the micro-controller can only control devices of 5v and below. relay We need to get the connection right for this relay — here is a connection diagram: ( ) Alt : Tessel 2 and Relay port mapping With the jumper cables, connect the 0 port of the Tessel to IN1 port of the relay. Do that for the rest of the ports as mapped below: 0 ←→ IN1 1 ←→ IN2 2 ←→ IN3 3 ←→ IN4 The following image shows the required wiring between the Tessel and the relay: ( ) Alt : Showing I/O connection as well as GND and 5v connection for relay The first thing that will throw you off is that we have a blue and brown cable running out of the GND and VOC ports, respectively. These GND port stands for ground and that is how you ground the relay. This means you need to connect it to the GND of the Tessel 2. The VOC is 5v power source for the relay and it has to go to the 5v port of the Tessel as well. On the Tessel 2, here is how the blue and brown cables run into the Tessel’s GND and 5v ports: ( ) Alt : GND and 5v connection Relay ←→ Fan We have seen how to connect the IoT board to the relay, now we need to connect the relay to the fan: ( ) Alt : Relay to fan connection Programming the Tessel 2 We want to be able to control the fan from our phones and laptops. One way we can do this is to have a node server run on the Tessel. This is totally possible. You can have a usual node server run on Tessel and access the Tessel from an IP address. With all your connections still in place, make sure the Tessel is connected to your computer and run `t2 list` to make sure it’s all setup. To create a code project, cd into the folder you want to code to live and run the following: t2 init && mkdir public This will setup a Tessel project with a file. It will also create a public folder for the browser client app. package.json Install the following node packages: npm install --save express body-parser socket.io tessel tessel-gpio-relay A node server Create a file in the root of your Tessel project with the following content: server.js path = ( ); relaylib = ( ); tessel = ( ) express = ( ); bodyParser = ( ); app = express(); http = ( ).Server(app); io = ( )(http); port = process.env.PORT || ; relay = relaylib.use(tessel.port[ ], [ , ]); app.use(bodyParser.json());
app.use(bodyParser.urlencoded());
app.use(bodyParser.urlencoded({ : })); app.use(express.static(path.join(__dirname, ))); app.get( , {
  res.sendFile(path.join(__dirname, ));
}); http.listen(port, { .log( + port + ,
  );
}); // Dependencies const require 'path' const require 'tessel-gpio-relay' const require 'tessel' const require 'express' const require 'body-parser' const const require 'http' const require 'socket.io' // PORT const 80 // Setup relay ports const 'B' 1 2 // Express middlewares extended true // Server public folder as static content folder 'public' // Index page route '/' ( ) function req, res '/public/index.html' //// websocket code coming soon... // Listen to port ( ) function console 'Your server is up and running on Port ' '. Good job!' This is an express middleware and what is going on is beyond the scope of this article. In summary, we have setup an express HTTP app and a websocket using . The route responds to the index requests sent to our server. socket.io app.get Note how we are using the relay library and the Tessel library to setup a port on the Tessel and map it to the relay IN1 and IN2. As for the content shown in the , create an file in the folder with the following: index.html index.html public Set a Color Set Mode <!DOCTYPE html> < = > html lang "en" < > head < = > meta charset "UTF-8" < = = > meta name "viewport" content "width=device-width, initial-scale=1.0" < = = > meta http-equiv "X-UA-Compatible" content "ie=edge" < > title </ > title < = = > link rel "stylesheet" href "style.css" </ > head < > body < = > h1 id "state" </ > h1 < = = > form method "POST" action "" < = = = > input type "button" onClick "toggleFan()" value "FAN" </ > input < = = = > input type "button" onClick "toggleSwing()" value "SWING" </ > input </ > form < = > script src 'https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.3.0/socket.io.dev.js' </ > script < = > script src "script.js" </ > script < > script socket = io(); modePicker = .getElementById( ); {
      socket.emit( , );
    } {
      socket.emit( , );
    } const const document 'statePicker' ( ) function toggleFan 'fanChange' 'CHANGE' ( ) function toggleSwing 'swingChange' 'CHANGE' </ > script </ > body </ > html Two controls — and represented and buttons. The intention is that when is clicked, the fan should go on but when is clicked, the fan would start swinging to spread across the room. fan swing FAN SWING The buttons have event listeners on them calling and respectively. toggleFan toggleSwing In the script file, we are using to emit events on the websockes back to the server. Now we need to go back to to listen to the events. socket .io server.js Kicking the relay Once the events are emitted from the web app, we need to listen to it and toggle the relay: io.on( , socket => { .log( );
  socket.on( , data => {  
    relay.toggle( , { (err) .log( , err);
    });
  });
  socket.on( , data => {
    relay.toggle( , { (err) .log( , err);
    });
  });
}); 'connection' console 'Connected...' 'fanChange' 1 ( ) function toggleOneResult err if console "Err toggling 1" 'swingChange' 2 ( ) function toggleOneResult err if console "Err toggling 1" When the event is received, we can either toggle the of the relay to start or turn off the fan, we can also make the fan swing or not with . IN1 IN2 Starting the Tessel Before we run the Tessel, we need to find the IP address to reach it with. To get the IP, run the following command: t2 wifi This will take print the network information of your Tessel including the IP address: Looking your Tessel . Connected HomeFan. SSID: wifi.com.ng Beast Address: 192.168.4.110 Signal Strength: (61/70) Bitrate: 58 Mbps INFO for .. INFO to INFO INFO IP INFO INFO Copy the IP address, then run the following: t2 run server.js Make sure your computer or phone is on the same wifi network with the Tessel 2 then visit the IP address and you should see the app. Click the fan button to turn on the and you can also swing using the button. FAN SWING ( ) Alt : App UI What’s Next? If you followed to this point, then you have done all the hard work it takes to make a smart device. The next thing you would want to try is to control your device from a different network. Currently we rely on the computer/phone to be on the same wifi as the Tessel — most times, this is totally fine. Sometimes though, you want to be able to control your device when you are not at home. To do this you need to connect your IoT to a hub. You can apply the technique in to connect your device to IoT hub and control it from a cloud. this article You can also use to start or stop this fan based on the temperature of the room. temperature sensors

Home Cooling Fan Made Smart with JavaScript [Tutorial]

Although the Bancor Protocol is unique, you don’t need a degree in quantum computing to understand it. The protocol introduces a new standard for enabling liquidity between tokens through a network of interconnected smart contracts. Each contract, known as a , acts as an on-chain liquidity pool that performs pricing and conversions between any integrated token in the network, with predetermined and foreseeable terms. Bancor “relay” Traditional exchanges work by matching buy and sell orders in a bid/ask system using order books or a matching engine to fulfil trades. When there are enough buyers and sellers of a token, this system generally works well; however, it assumes a given level of volume and interest in a token. If a token has low volume at any time, it not only becomes difficult to buy or sell, but individual transactions can cause unpredictable price swings, reducing a token’s usability and adoption. Because relays don’t rely on matching buyers and sellers, and instead use on-chain “reserves” as always-available liquidity pools, they have the potential to remove a token’s dependency on trade volume and ensure liquidity for tokens. Even low-volume tokens can offer frictionless conversions for their users — in their earliest days or during periods of decreased volume. constant In order to understand how relays work, let’s first consider a thought experiment. Imagine you had to find the fair market value of watermelons priced in terms of grapes. How many grapes equal one watermelon? Cryptocurrency markets face similar issues when converting between tokens. Bancor Protocol suggests a solution for price discovery and token liquidity through the use of relays. Relays are programmed to receive and dispense tokens according to a predetermined formula which continuously measures the supply of tokens staked to the network. To achieve this functionality, a relay maintains two token “reserves”, each holding a specific type of token. Relays adjust the prices of each token in terms of the other, in order to maintain a fixed 50/50 ratio between the two reserves. For example, a relay created with and will allow a user to sell a watermelon to the relay and receive grapes in return. Such a transaction would add a watermelon to the relay’s watermelon reserve, and withdraw grapes from the relay’s grape reserve. In order for the relay to maintain its 50/50 reserve ratio, the relay rebalances prices to the price of the sold token (watermelons) and the price of the purchased token (grapes). This continuous rebalancing is designed to reflect real-time supply and demand for watermelons and grapes in the network. watermelon tokens grape tokens decrease increase Here’s a quick video by explaining this process: EOS Weekly body[data-twttr-rendered="true"] {background-color: transparent;}.twitter-tweet {margin: auto !important;} That time used watermelons & grapes to explain the Bancor Protocol & automated liquidity. 🍉🍇 Full Video: #DeFi #Tokens @eosweekly https://t.co/ZnaT7FxBhq https://t.co/ElzavqYOqB — @Bancor function notifyResize(height) {height = height ? height : document.documentElement.offsetHeight; var resized = false; if (window.donkey && donkey.resize) {donkey.resize(height); resized = true;}if (parent && parent._resizeIframe) {var obj = {iframe: window.frameElement, height: height}; parent._resizeIframe(obj); resized = true;}if (window.location && window.location.hash === "#amp=1" && window.parent && window.parent.postMessage) {window.parent.postMessage({sentinel: "amp", type: "embed-size", height: height}, "*");}if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.resize) {window.webkit.messageHandlers.resize.postMessage(height); resized = true;}return resized;}twttr.events.bind('rendered', function (event) {notifyResize();}); twttr.events.bind('resize', function (event) {notifyResize();});if (parent && parent._resizeIframe) {var maxWidth = parseInt(window.frameElement.getAttribute("width")); if ( 500 < maxWidth) {window.frameElement.setAttribute("width", "500");}} The amount of liquidity staked in a relay (a metric known as “ ”) depends on how much the liquidity provider deposits in the smart contract. If a user performs a large conversion relative to a token’s liquidity depth, the conversion will cause the price of the desired token to move as the conversion is processed, also known as price “ ”. While slippage is expected in nearly every token conversion (albeit in infinitesimally small amounts for highly liquid tokens), a unique characteristic of Bancor relays is that they pre-calculate a token’s slippage prior to a user submitting a conversion, giving users the ability to see how much of an asset they’ll receive for any conversion with compared to solutions based on order-matching. liquidity depth slippage far greater accuracy Relays are just one implementation of the Bancor Protocol, characterized by their fixed 50/50 reserve ratio. Upcoming blog posts will explore additional implementations of the protocol with different and dynamic reserve ratios. Reserve functions can be designed to favor certain market behaviors or promote certain economic incentives. A “ ” emerges when there are two or more relays connected to one another by holding the same token in one of their reserves. Through transference, if one relay holds tokens A and B, and another relay holds B and C, token A becomes convertible for token C via token B. Liquidity networks allow integrated tokens to be autonomously convertible for one another without the need for a central entity, across an unaffiliated and unlimited community of network users. liquidity network Today more than 140 relays form the Bancor Network, with each relay funded by an independent “liquidity provider” who serves as a node in the network . To on the Bancor Network, a liquidity provider stakes an amount of one type of token (ERC20 or EOS-based) along with Bancor’s Network Token (BNT) in a smart contract. BNT is the mechanism through which in Bancor’s liquidity network, automating on-chain convertibility across 1000s of live token pairs, including . Until now, liquidity providers have collectively staked over $12.7M in ERC20 and EOS tokens to the Bancor Network. set up a relay relays connect cross-blockchain conversions The figure below shows a simple implementation of a liquidity network consisting of only two Bancor relays (Token A and Token B), where the price of each token as well as BNT is set to $1: Token A is converted into Token B by: Sending one Token A to Token A Relay, increasing the Token A supply in the Relay to . 11 As Token A Relay sends one BNT, decreasing the supply of BNT to . 9 BNTs This creates an imbalanced Relay. To balance it, the Relay decreases the price of the sold Token A — setting its price using the Relay’s new token balances . 9(BNT)/11(A) or $0.81 The withdrawn BNT is automatically sent to the Token B Relay, which increases the supply of BNT inside the Token B relay to . 11 BNTs Token B relay sends one Token B to the user, which decreases Token B supply to . 9Bs This once again creates an imbalanced relay. To balance it, the relay increases the price of the purchased Token B to . 11(BNT)/9(B) or $1.22 As shown above, tokens on Bancor their price when they are and when they are , so users know they are always getting a fair price based on real-time token supply and demand. increase purchased decrease sold Since its creation in 2017, Bancor Protocol has enabled billions in conversions for tokens of all sizes, providing automated liquidity through an open and decentralized protocol — similar to how protocols like HTTPS and SMTP unlocked open access to Internet and email services. Using relays, the Bancor Protocol reimagines asset conversions from a human-mediated process to an automated process that occurs fully on the blockchain between a user and a smart contract. In the future, any user will be able to add a token to the Bancor Network via self-service functionality, allowing even crypto beginners to create instantly liquid tokens and tokenize new kinds of online ecosystems — without worrying about creating enough volume or securing listings to ensure liquidity from day one. About The Bancor Protocol is an on-chain liquidity protocol revolutionizing the way people create and share value by enabling constant convertibility between tokens. Conversions via Bancor Protocol are executed against on-chain liquidity pools using automated market makers to price and process transactions without order books or counterparties, allowing for faster, cheaper and more predictable conversions across 9700+ ERC20 and EOS token pairs, including non-custodial conversions between blockchains. Bancor How to get involved with Bancor to the Bancor Network. Add your token Checkout , jump in and contribute code. Github Build a dApp with the . Bancor APIs Support us on . social media . We have new positions posting all the time. Join our team

How Bancor Relays Work

Open frameworks played an important role on the internet we see today. If you want to build a web app from scratch you have to do a lot of things yourself (listening to requests from port 80, writing a wrapper to interact with your database, etc). But, people hardly code from scratch. Instead, they use MVP frameworks like Laravel, CodeIgniter, Django, Flask, etc. You can reuse their code which was refined over time by the community. This process can save you time and help you take your ideas to market faster. Building autonomous systems that can facilitate transactions on Ethereum from scratch is hard and time-consuming. Your code needs to be optimised because you have to pay for the computational power utilised. In other words you can build a decentralised exchange using 0x APIs. 0x is an open protocol that provides you the architecture to enable decentralised trading. What is a Decentralised Exchange? In a decentralized exchange, trading happens directly between people’s wallets. The decenteralised exchange doesn’t hold their user’s assets. Traders create an order at the price in which they want to buy or sell and pre-authorises a transaction. The order is broadcasted through out the network, traders who are willing to counter the order fills it. If Sara wants to exchange BAT for ETH, she specifies the price at which wants to sell it and create an order in a decentralized exchange. The decentralised exchange pings her wallet to take her approval in order to pre-authorise the transaction. After her approval, the order is visible to other traders who can choose to fill the trade. Mark chooses to fill the trade, he authorizes the transaction through his wallet. The trade happens, Sara’s BAT token get transferred to Mark’s wallet and his ETH is sent to her wallet. The trade didn’t require a middleman to hold tokens. 0x smart contracts are rent free and open source. It is backed by a strong community who continuously refine and optimise its code. With the help of 0x, you can focus on the core business logic and worry less about the architecture. You can use their APIs to easily program money or even build a decentralised exchange/relayer. We already have a lot of projects built on top of 0x. , , , (Acquired by Coinbase) are the popular relayers built on 0x. Radar Relay ERC Dex DDEX Paradex These relayers can charge its users a fee for its services. This is a win-win situation for both 0x and relayers because they will individually market and compete to build quality services on top of 0x. They are called relayers because they use 0x’s infrastructure to enable trading. When relayers attract more users, 0x will start growing as an open platform. This would also enhance 0x architecture since its open source and contributed by the community. Relayers thus don’t have to worry about maintenance and system upgrades, they can focus on the core business model. How Does Trading Happen on 0x? In order for the trading to happen, we need a system to create, match and fill orders. As discussed in the earlier example, Sara creates the order and Mark sees the order and chooses to fill it. These created orders need not be filled. Frequently writing data on Ethereum is inefficient and costly. 0x uses a brilliant approach and take the order creating, matching and filling process off-chain. 0x matches orders by broadcasting signed messages across the network, only when an order is filled, trade is executed on the blockchain. This approach reduces the load on the blockchain and enables efficient trading. The Four Key Components of 0x Protocol 0x protocol is made up of four key components. Makers, takers, relayers and smart contracts. Let’s see how these components worth together to enable decentralized trading. Relayers offers interfaces(web or mobile apps) to users. There is a fee for using the 0x platform which needs to be paid using ZRX. Relayers offer competitive pricing to its users. The makers are users who want to sell or buy tokens. In one of the earlier examples we discussed, Sara is a maker who wants to trader her BAT tokens. Makers use the relayer’s interface(eg. Radar Relay) to create orders by authorizing the transaction using their private keys. The order will contain parameters like the tokens they like to trade, the price at which they want to buy or sell, the relayer fee and time in which the order will expire if it’s not filled. Relayers validates the maker’s order and appends it to their order book. These orders are also visible to other traders using the relayer. When a trader chooses to fill the order created by the maker he becomes a taker. Some relayers automatically matchmakers who make opposite orders. Once the order is matched, the Ethereum smart contract executes the order on-chain. Tokens get exchanged directly between the wallets of maker and taker. The relayer receives the agreed amount of fee. Relayers are only one of the use cases of 0x, the potential applications of 0x are infinite, let’s have a look at some of the application. Applications of 0x The process of creating a decenteralised organization on Ethereum, issuing tokens, developing code to manage the governance by voting, etc requires technical resources. It’s also time-consuming and costly. Aragon is a decentralised application that uses 0x protocol to help users easily built decentralised organisations on Ethereum. Fintech products that help people invest their money efficiently aren’t something new. However, these products lack transparency. Auctus is retirement planning platform that makes use of the 0x protocol. You get human and robotic advisory to help you manage your assets efficiently. Advisors are incentivised based on their advice. A lot of experts who make predictions, most of these predictions fail. What if we can make them accountable for their predictions? Augur is a prediction market platform that uses 0x protocol. An expert can make predictions on the platform by holding their money. If their prediction comes true they are incentivised else they lose their money. The kind of applications that can be built on 0x is vast. We are yet to see its true potential. You can have a look at the story written by from the 0x team. “18 Ideas for 0x Relayers in 2018” Tom Schmidt This story is part of our “ ” Series. In the second story, we have reviewed relayers built on 0x. Deep Dive Into ERC20 Ecosystem _In our previous story, we introduced 0x. In this story, we have reviewed popular relayers built on 0x, here is our…_medium.com Here is Our Review of Decentralised Exchanges Built on 0x Claps Please 👏 , Thank You 😊. F_ollow us Hackernoon and me (_ Febin John James ) for more stories. We are also taking an initiative to bring people working in the crypto space closer. If you are a developer, designer, marketer, writer, trader, entrepreneur, etc in the crypto-space please fill this form . We will curate the list and share it with you, that can help you build your network.

How Can 0x Help You Build Decentralised Applications

Many companies and developers ask themselves this question if they start talking about managing data inside a react app. Usually, criteria are simple: easy to set up, easy to work with, decent documentation, large community. If we start considering and by these criteria which one will win? Let’s figure it out! relay redux What is Relay? is a data manager from Facebook. It was initially built for react-native apps but later it became a tool for web apps as well. Relay The idea of Relay is simple: you app needs to fetch only data your users need. It’s declarative way of describing what data is needed. A simple relay query would look like this: We ask for user’s first name and last name. The server will only return to us these two fields. No more. Relay requires your server side to support requests. query language Relay has some outstanding features out of the box, such as , , (removing, adding, updating data). caching requests optimistic updates smart data updates What is Redux? I guess that everyone who reads this story knows or at least has heard about . It is a state container for javascript apps. It gives you an opportunity to keep your state in one place. The idea of redux is to have one-place-of-truth. Any data manipulation should be done using redux, whether you dispatch an action to update your data or getting it. redux Redux itself is pretty simple and has only a few internal things( , , ), everything else is your imagination. It is pretty solid and stable library with a huge community over the world. store dispatch/action reducer Redux doesn’t have any features like Relay has. Whatever you want from Redux you have to build yourself(or find it in GitHub). You decide how to fetch, what data to fetch, how to store it and how to update it. Redux doesn’t require anything from your server side, it only requires you to follow simple . rules When to use Relay? Obviously, you need to use Relay if your server side is supporting graphql queries. Relay takes all queries which need to be fetched from the server side and send only request to the server side which speeds up app noticeably. Creating an XHR for every request is expensive this is why engineers from Facebook decided to collect and combine all queries into one XHR. one Relay was made to work with a big amount of data, so if your app is going to be large in terms of data stored on a client-side you need to give Relay a try for sure. If you going to use React-Native you also might find Relay is suitable, because Relay only asks for data it needs, so for users with 3G network connection it would be crucial to saving some traffic. You are going to give the best user experience you can, so you may also consider relay because of its cool features: optimistic updates, caching requests and etc. You have time to spend on investigating some problems and things because documentation of Relay is not ideal. Sometimes you need to give deeply into the source code. When to use Redux? Your app is simple in terms of data usage. You don’t need to update many things in your store which depend on something else. A good example would be a todo app, you don’t really need to have any data manager there, but redux would be ok. Your app is using web-sockets. Redux is much simpler to work with web-sockets, all you need to do is dispatch an action when a message comes. Easy! You don’t have graphql on your server side. You don’t have time to set up a data manager and your deadline is yesterday. You don’t need to give the best UX. No optimistic updates, no caching. Which one should you choose? Of course, it depends on an app you are building, in one hand we have Relay: Better UX our of the box. Better data fetching. and in another hand we have Redux: Easy to set up and to work with. Does not require additional knowledge about the server side. It is absolutely up to you which one you pick. This kind of decisions has to be made in the begging of development so be careful with your desires. Conclusion Whether you use relay or redux or any other tools it only matters how you use them. There is no bad tool or language there are wrong decisions make at the very first place. You can always use Relay with Redux, as I do. I use Relay to store business data and Redux for some temporary things such as themes, locales, filters. Like the story? Share & Clap it. Thanks.

Relay vs Redux: Which one you should choose?

Originally published at melvinkoh.me Suppose your task takes about 20 seconds to finish before responding your client. Imagine you are the user of your application. It happens that a lot that processing can be actually be spared until later time whenever user makes a request to your site. AJAX is one way of doing tasks asynchronously, but we want to run our Python code asynchronously. Therefore, we resort to using Task Queue and Message Broker. The typical process flow of a request to Django app: 1. Receive request 2. Server relay to a specific View 3. Process request in View 4. Respond to request Say we want to fetch some data externally and process them whenever there is an update. Sounds familiar right? Yes, you can think of it as a Webhook on your CI server. In this post, I won’t be discussing about why I choose Redis over other message broker like , or . The scope of this post is about applying task queue to facilitate execution of asynchronous task in Django. If you new to task queue, have no idea how to implement async tasks, or looking for solution to integrate Celery with Django, keep reading! RabbitMQ ActiveMQ Kafka Installation of Celery and Redis First, make sure you installed Celery and Redis interface, you can do so by downloading from PyPi. pip install celery redis Next, install , you can refer to from DigitalOcean. Redis Server this post If you are running on Docker, simply ‘up’ a Redis container using image in Docker Hub. Let’s get started! Initially, this is the structure of our project for demonstration: .├── api│   ├── apps.py│   ├── __init__.py│   └── views.py├── django_with_celery│   ├── __init__.py│   ├── settings.py│   ├── urls.py│   └── wsgi.py└── manage.py Let us add a URL entry and a View into our Django project. # django_with_celery/urls.pyfrom django.conf.urls import urlfrom api.views import BuildTrigger

urlpatterns = [  url(r'^api/trigger_build/', BuildTrigger.as_view()),]

# api/views.pyfrom rest_framework.views import APIViewfrom rest_framework.response import Response

class BuildTrigger(APIView):  def post(self, request):    build_something() # This would take 1 minute to finish    return Response(None, status=201) From the BuildTrigger View, takes about a minute to finish execution. The whole process from sending Http request from client to receiving a response would definitely takes more than a minute. It is likely the HTTP client drop this connection if response time > connection timeout. Since the endpoint is to trigger a build, we should can run it after responding. build_something() build_something() To perform tasks asynchronously, we use a task queue to queue all pending tasks. In our case, we will use , an asynchronous task queue based on distributed message passing and Redis as the message broker. Celery To integrate Celery with Django, create a in the project root directory. Then another Python file in your django_with_celery app directory. __init__.py celery.py In your , add the following code: celery.py # django_with_celery/celery.pyfrom __future__ import absolute_importimport osfrom celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'django_with_celery.settings') # DON'T FORGET TO CHANGE THIS ACCORDINGLY

app = Celery('django_with_celery')app.config_from_object('django.conf:settings', namespace='CELERY')app.autodiscover_tasks() In , we define the environment variable . The last line, will run through all our modules and look for asynchronous task. celery.py DJANGO_SETTINGS_MODULE autodiscover_tasks() Next, we define these in our of our project. __init__.py #./__init__.py

from __future__ import absolute_import, unicode_literalsfrom django_with_celery.celery import app as celery_app

__all__ = ['celery_app'] After adding these codes, add the following variable into your main , in our case, the . settings.py django_with_celery/settings.py CELERY_BROKER_URL = 'redis://localhost' This would define the host of our Redis instance. Celery will look for variables with ‘CELERY_’ prefix in the settings.py defined in system environment. Now, all our integration is done but definition of async tasks. To define an async task, simply import and add the decorator to each method or function. @shared_task from celery import shared_task

@shared_taskdef build_something():  # some code here You may find some tutorial suggest you to define all async task in a separate module. Well, it is entirely up to you, as by enabling autodisover, Celery will look for all task with decorator. @shared_task By adding decorator, you method can now run asynchronously, but it doesn’t run naturally. We have to call the method in a way telling it to run asynchronously. To do so, simply call your method with the suffix or @shared_task apply_async() delay() build_something.apply_async()# ORbuild_something.delay() There are some differences between the two method regarding configurability. You can refer to for more details. Celery documentation All good, but not done Until this step, all codes required to run tasks asynchronously are done, but you will need few more step to let your tasks run properly. Make sure your Redis is up and running. Run to start your server if you are running it in your local machine. You can also run to attempt connection to your Redis server. redis_server redis_cli We need to spawn workers. Open your Terminal. Run the following command from your project root: celery -A django_with_celery.celery worker -l DEBUG -E This will spawn a worker for our app. Run your app Now you should be able to run your tasks, whenever a task is queued into Celery, it will be logged to your console running command from above. Handy Tool: Flower is a monitoring tool for Celery. You can learn more about it from their . It provides real-time monitoring to your Celery clusters, remote control, broker monitoring, HTTP API, etc. Flower GitHub Your clap will definitely drive me further. Give me a clap if you like this post.

Asynchronous Tasks with Celery + Redis in Django

This tutorial assumes that you’re already familiar with (CRA) and a little bit of , and just looking for some examples of how to use them together. Here you will learn: Create React App Relay How to modify Create App setup to use “babel-plugin-relay” in its config React How to configure Relay Compiler How to use Relay’s component <QueryRenderer /> How to fetch data with Relay as the user navigates though the site Note, that many tutorials on the Internet covering the previous version of Relay (aka Relay Classic). It differs a lot from Relay Modern, so it’s better to just ignore those not to confuse yourself. — Visit repository on GitHub for a complete Create React App + Relay Modern example. TL;DR [**kriasoft**](https://github.com/kriasoft)/[**react-static-boilerplate**](https://github.com/kriasoft/react-static-boilerplate) Injecting “ ” into CRA babel-plugin-relay As you probably know, Create React App is not very extensible. Basically, you are left with these main options when it comes to customizing Babel/Webpack configs: : Run and tweak Babel/Webpack/PostCSS etc. configs in-place right in your project. But in that case, you will not be able to easily upgrade your app to a new version of React-related tooling. This defeats the purpose of using Create React App in the first place, as opposed to using some popular boilerplate, such as (RSK), which you can clone and yet being able to pull and merge updates back into your project down the road. Options 1 yarn eject React Starter Kit : Fork repository, and use a patched version of the “react-scripts”. Note that keeping your fork up to date could consume some of your free time which you could better spend on something more useful. See as an example, that allows extending CRA with custom config overrides and comes with a server-side code support. Option 2 create-react-app React App SDK : Create a script that will automatically patch your “react-scripts” npm module whenever you run or . I personally find this option more practical as it helps me get things done faster during the initial setup as well as keeping my project up to date with lesser amount of efforts in the . Option 3 yarn build yarn start future After bootstrapping a new project (by running ), you will need to install Relay’s run-time and dev dependencies: yarn create react-app $ yarn add relay-runtime react-relay$ yarn add relay-compiler babel-plugin-relay --dev Next, create “setup.js” file in the root of your project with the following contents: const fs = require('fs');const path = require('path');const file = path.resolve('./node_modules/babel-preset-react-app/index.js');const text = fs.readFileSync(file, 'utf8');if (!text.includes('babel-plugin-relay')) {  if (text.includes('const plugins = [')) {    text = text.replace(      'const plugins = [',      "const plugins = [\n  require.resolve('babel-plugin-relay'),",    );    fs.writeFileSync(file, text, 'utf8');  } else {    throw new Error(`Failed to inject babel-plugin-relay.`);  }} Finally, update the “scripts” section in file to run this script before : package.json react-scripts <command> "scripts": {  "build": "node ./setup && react-scripts build",  "test": "node ./setup && react-scripts test --env=jsdom",  "start": "node ./setup && react-scripts start"} Now, whenever you run , , or the Babel compiler will use “babel-plugin-relay” as required by Relay Modern. yarn build yarn test yarn start Configuring Relay Compiler The next step is to configure Relay Compiler, the purpose of which is to find all the queries in your code, pre-compile them and save to files consumed by “babel-plugin-relay” from the previous step. graphql`…` __generated__/*.graphq.js In order to do so, first, you need to save the text-based representation of your GraphQL schema into a file inside of your project, assuming that your React app is intended to work with some external GraphQL API. And then add one more into that will run . It may look something like this: npm script package.json relay-compiler "scripts": {  ...  "relay": "curl https://graphql-demo.kriasoft.com/schema -o ./src/graphql.schema && relay-compiler --src ./src --schema ./src/graphql.schema} For this exercise, we are going to use an existing GraphQL demo API hosted at ( ). https://graphql-demo.kriasoft.com source code Before you can run , make sure that you have Facebook’s tool installed on you dev machine. yarn relay Watchman Now, whenever you change some GraphQL/Relay query in your code, you would need to run over again, or keep it running in a separate shell window in watch mode by running . yarn relay yarn relay -- --watch : Do I need to excluded generated by Relay Compiler files from my source control by appending to ? : Good question :) Yes, as a rule of thumb you don’t want any auto-generated files in your source code repository. Q __generate__/** .gitignore A Try putting the following piece of code into any of your source files (e.g. into ) and running : src/index.js yarn relay && yarn build import { graphql } from 'relay-runtime'; graphql`query { me { displayName } }`; If you can build the project without any errors, most likely that the previous two steps are done correctly. How to initialize a Relay client (environment)? This part is simple, just follow the official docs. Your Relay client (environment) will look something like this ( ): src/relay.js You can even use it directly without “react-relay” package if you want to. Here is an example: import { graphql, fetchQuery } from 'relay-runtime';import relay from './relay'; fetchQuery(relay,graphql`query { me { displayName } }`).then(...); In a real-world project, you would need to replace the hardcoded API URL in the code sample above with something like this: fetch(process.env.REACT_APP_API || 'http://localhost:8080', ...) ..so you could easily run your app in dev/test/prod environments. For more information about injecting environment variables into your app, refer to Create React App user guide. How to use <QueryRenderer /> component Relay Modern comes with a handy component that you can use at the top level of your app, somewhat similarly to Redux’s component. It will pass Relay’s environment (including Relay store and HTTP client) down to all the children React components via . Also it will handle updates for you, so you won’t need to re-render your components manually after running mutations. <QueryRenderer /> <Provider> context The logic looks like this — whenever a user opens your site, or navigates from one page / screen to another, you find the corresponding GraphQL query and a list of parameters (variables) for that page, pass it to <QueryRenderer> and let it do the job (it will fetch missing data and re-render affected children component). Your top-level React component ( ) will look something like this: src/App The code sample above uses “history” npm module for navigation and “universal-router” for resolving URL path to a route. The contents of looks as follows: src/history.js import createHistory from 'history/createBrowserHistory';export default createHistory(); It is a cross-browser wrapper around HTML5 History API, that allows you to respond to any changes caused by changes in initiated on the client-side, as well as modifying that state, e.g. by calling . window.location history.push(..) The contents of is a little bit more interesting. Given the list of application routes and a global router handler function, it initializes and exports an instance of the class. src/router.js universal-router BTW, in case with GraphQL/Relay it makes sense to use declarative routing approach (as opposed to imperative routes), meaning that all your routes contain just metadata and no handlers. At a bare minimum, each of your route can contain a URL path string (pattern), GraphQL query, and component to render, for example: const routes = [{path: '/posts/:id',query: graphql`query routeStoryQuery($id: ID!) {post: node(id: $id) { ...Post_post }}`,component: () =>import(/* webpackChunkName: 'post' */, './Post')},...] Now you can initialize the router by providing the list of routes and a global router handler (resolver) function, somewhat similar to this: import Router from 'universal-router';import { graphql } from 'relay-runtime'; const routes = [ ... ]; // see above export default new Router(routes, {resolveRoute({ route, next }, params) {if (!route.component) next();return {query: route.query,component: route.component(),variables: params,};}}); You would need to tweak this example a little to cover more use cases. The idea is that when the corresponding route is found (URL matched), it should start downloading the JavaScript chunk for that page / screen and at the same time pass query and variables to (see example above), effectively triggering data fetching for that route. The only issue, is that when QueryRenderer has finished fetching data, you need to make sure that async chunk loading has also finished its work (promise resolve) before you can render the page, for that purpose you use an intermediate (AppRenderer) component. QueryRenderer src/App You can put as much or as little metadata in your routes to suite your app, for example, you can put authentication rules like so: {path: '/admin/users',query: graphql`...`,component: () => ...,authorize: { roles: ['admin'] } // or, "authorize: true" etc.} With GraphQL / Relay you may want to fetch data for all of your components on a particular page / screen at once (as opposed to fetching data individually for each nested level of components), otherwise you would degrade the value of GraphQL a little. For a complete example of using Create React App with Relay Modern please visit — it’s a popular boilerplate for creating single-page apps on React/Relay stack, things like admin panels, dashboards etc. where you don’t need server-side rendering. You can use it not only as an example, but a seed for your React projects to save a good amount of time configuring everything from scratch. Feel free to ping me on or if you bump into any issues with it, I’d be glad to help. [**kriasoft**](https://github.com/kriasoft)/[**react-static-boilerplate**](https://github.com/kriasoft/react-static-boilerplate) Gitter Twitter : There is an for this project :) Your support is more than welcome! P.S. OpenCollective page

Stories, News & Mentions about RELAYTO

Relayto’s Stories on HackerNoon