Autometry

When I started working on a start-up nine months ago, this statement didn’t satisfy me or my co-founders: “There is no way to build a Slack bot more reliable than a Slack itself.” — common sense. Our product is an incident management tool called . It’s a Slack app and yes, it should be super reliable. We didn’t leave our SE jobs in Silicon Valley and London to give up when faced with our first technical challenge. Amixr.IO What’s a reliable web service? And what’s not? In terms of reliability, Slack is pretty good. They do a lot of good things. For example they keep users posted about problems through and . status page twitter Unfortunately, Slack has also experienced serious periods of downtime, and users remember that. That’s why users don’t expect an uptime-critical service, such as the our tool, to rely on it. We’ve found a way to achieve that goal. Over the last few months, our service has proved much more reliable than Slack, and we’ve even unveiled an SLA because we’ve built something that customer can rely on. Six simple principles described below helped us here. 1. Draw a red line Any Slack app, as well as any other bot for Facebook or Telegram, uses a web server. Slack is just an interface that allows users to interact with a system. That means we can draw a red line across all of our applications. Parts that are connected to Slack are in danger; other parts depend only on us. Imagine you’re creating a small Slack app. Its purpose is to post a message about new cards on your Trello board. The bot could be a simple web server that will wait for a from Trello in order to post a new message to Slack. It could be as simple as: webhook slackclient SlackClient rest_framework.views APIViewё sc = SlackClient(<bot_access_token>)
        sc.api_call( ,
           channel=<channel_id>,
           text= ,
        ) from import from import : class TrelloForwarderAPIView (APIView) : def get (self, request) "chat.postMessage" "New Cards in Trello detected" Let’s imagine that sc.api_call raises an Exception because the Slack API doesn’t work. I’m sure it won’t last long, so there’s no need to panic. However, you won’t be able to publish a message about this particular Trello card. It will be missed, forever, and your business could be damaged. Now, let’s draw a line between the Trello part and the Slack part and sandbox everything where Slack could cause data loss. To do that, we’ll receive a message from Trello, write it to a queue, and then only remove it from the queue when the message has been successfully posted. celery shared_task slackclient SlackClient rest_framework.views APIView sc = SlackClient(<bot_access_token>)
    sc.api_call( ,
        channel=<channel_id>,
        text= ,
    ) notify_slack.apply_async() from import from import from import @shared_task(autoretry_for=(Exception,), retry_backoff=True, max_retries=None) : def notify_slack () "chat.postMessage" "New Cards in Trello detected" : class TrelloForwarderAPIView (APIView) : def get (self, request) We use Celery, RabitMQ, and Django. Celery’s apply_async method publishes a task to RabbitMQ. In our case, it’s a highly available cluster. Celery workers look out for new tasks and try to execute them until they’re executed, without exception. Now, we can be sure that we won’t lose data if the Slack API causes exceptions on our side. 2. “Broken” doesn’t always mean that “everything is broken” Slack is huge. It has millions of users online and uses multiple servers in regions across the world. If something goes wrong in one place, it doesn’t mean that everything is broken at another location. Even if 99% of servers aren’t able to proceed with a request, there’s another 1% that can. That’s exactly what to Slack in June when its servers weren’t able to process a small fraction of our requests. However, our server didn’t give up, and sent everything successfully. Just nine messages got stuck at one moment, but we’ve sent them successfully since then. happened 3. Be notified early We love it when Slack works, but we need to know when it doesn’t. That’s why we monitor Slack ourselves. We check message delivery, verify API responses, and so forth. We proactively monitor Slack and sometimes detect issues, such as the one detailed in this message regarding the , before anyone else. blocks API If you’re building your service on top of another service, then write scripts and automated tests that proactively monitor the third party. That’s the only way to be the first to learn about a problem. 4. Prepare a Plan B OK, so you’ve built an awesome Slack app that works even when Slack doesn’t. How can you be sure that everything is ready? . It’s just a small example of a fascinating subject called chaos engineering ( ). Simulate a problem, even in production, then check your monitoring and your backup systems. Try simulate Slack downtime yourself https://principlesofchaos.org/ A huge part of this trick is known as “graceful degradation.” It’s the ability to deactivate non-critical parts if they don’t work as expected. In the case of total Slack downtime, our app will switch to a back-up delivery channels, such as e-mail, phone, or another messaging service. It reduces functionality and delivers business value anyway. 5. People should be close We don’t let a critical situation evolve without qualified people watching the process carefully. Even if a case-critical situation is 100% what we expected and recently tested for, there’s still a huge chance of the unexpected occurring. Sometimes, engineers consider how to fix problems temporarily while causing as little damage as possible. For instance, during the issue with the blocks API, we were able to find a workaround pretty quickly. We dealt with the issue before Slack fixed the problem on its side. 6. Talk with clients When discussing outages, we’ve chosen a proactive strategy. We actively inform our users about outages before they notice anything suspicious. If that happens, they won’t consider our service unreliable — they’ll be confident that we know about the problem and are doing our best to fix it. Fun fact: At the very beginning ,we did not have reserve notification channels about a downtime. For the first time, I had to look for users on social networks, write on Facebook, introduce ourselves, and make sure that we didn’t let anyone down. It was really creepy, but, in the end, people reacted positively and became regular users. The six principles described above are universal. They can help to build a reliable service on top of any other third party, and they’ve already helped us with Slack. Each product has different requirements so it's up to you which practices to implement.

How to build a Slack App more reliable then Slack

Ever struggled with large file upload in PHP? Wondered if you could continue uploading where you left off without re-uploading whole data again in case of any interruptions? If this sounds familiar to you, then keep reading. Photo by on rawpixel.com Unsplash File upload is a common task we do in almost all of our modern web projects. With all different tools available, it is not that hard to implement file upload feature in any language. But, still, when it comes to large file upload things gets a bit complicated. Say, you are trying to upload a fairly large file. You have been waiting for more than an hour already and the upload is at 90%. Then suddenly, your connection drops or browser crashed. The upload is aborted and you need to start from the beginning. Frustrating, isn’t it? Even worse, if you are in a slow connection, like many places in the world, no matter how often you try you will only be able to upload first part of the upload every time. In this post, we will see an attempt to solve this problem in by uploading files in resumable chunks using tus protocol. PHP Resumable File Upload in PHP — Demo What is tus? Tus is a HTTP based . Resumable means we can carry on where we left off without re-uploading whole data again in case of any interruptions. An interruption may happen willingly if the user wants to pause, or by accident in case of a network issue or server outage. open protocol for resumable file uploads Tus protocol was in May 2017. adopted by Vimeo Why tus? Quoting from : Vimeo’s blog We decided to use tus in our upload stack because the tus protocol standardizes the process of uploading files in a concise and open manner. This standardization will allow API developers to focus more on their application-specific code, and less on the upload process itself. Another main benefit of uploading a file this way is that you can start uploading from a laptop and even continue uploading the same file from your mobile or any other device. This is a great way to enhance your user experience. Pic: Basic Tus Architecture Getting Started Let’s start by adding our dependency. $ composer require ankitpokhrel/tus-php is a framework agnostic pure PHP for the tus resumable upload protocol v1.0.0. tus-php server and client implementation _tus-php - 🚀 A pure PHP server and client for the tus resumable upload protocol v1.0.0_github.com ankitpokhrel/tus-php : Vimeo is now using in of their . Update TusPHP v3 Official PHP library for the Vimeo API Creating a server to handle our requests This is how a simple server looks like. // server.php $server   = new \TusPhp\Tus\Server('redis');$response = $server->serve(); $response->send(); exit(0); // Exit from current PHP process. You need to configure your server to respond to a specific endpoint. For example, in Nginx, you would do something like this: # nginx.conf location /files {try_files $uri $uri/ /path/to/server.php?$query_string;} Let’s assume that the URL to our server is So, based on above nginx configuration we can access our tus endpoints using . http://server.tus.local http://server.tus.local/files. Now, we have following RESTful endpoints available to work with. # Gather information about server's current configurationOPTIONS /files # Check if the given upload is validHEAD /files/{upload-key} # Create a new uploadPOST /files # Resume upload created with POSTPATCH /files/{upload-key} # Delete the previous uploadDELETE /files/{upload-key} Check out the for more info about the endpoints. protocol details If you are using any frameworks like Laravel, instead of modifying your server config, you can define routes to all tus based endpoints in your route file. We will cover this in detail in another tutorial. framework Handling upload using tus-php client Once the server is in place, the client can be used to upload a file in chunks. Let us start by creating a simple HTML form to get input from the user. <form action="upload.php" method="post" enctype="multipart/form-data"><input type="file" name="tus_file" id="tus-file" /><input type="submit" value="Upload" /></form> After a form is submitted, we need to follow few steps to handle the upload. Create a tus-php client object // Tus client $client = new \TusPhp\Tus\Client('http://server.tus.local'); The first parameter in the above code is your tus server endpoint. 2. Initialize client with file metadata To keep an upload unique, we need to use some identifier to recognize the upload in upcoming requests. For this, we will have to generate a unique upload key which can be used to resume the upload later. You can either explicitly provide an upload key or let the system generate a key by itself. // Set upload key and file meta $client->setKey($uploadKey)->file($_FILES['tus_file']['tmp_name'], 'your file name'); If you don’t provide upload key explicitly, above step will be something like this: $client->file($_FILES['tus_file']['tmp_name'], 'your file name'); $uploadKey = $client->getKey(); // Unique upload key 3. Upload a chunk // $chunkSize is size in bytes, i.e. 5000000 for 5 MB $bytesUploaded = $client->upload($chunkSize); Next time, when you want to upload another chunk you can use same upload key to continue. // To resume upload in next request $bytesUploaded = $client->setKey($uploadKey)->upload($chunkSize); Once the upload is complete, the server verifies upload against the checksum to make sure the uploaded file is not corrupt. The server will use algorithm by default to verify the upload. sha256 The full implementation of the demo video above can be found . here Handling upload using tus-js-client is a sleek, modular file uploader plugin developed by same folks behind tus protocol. You can use uppy to seamlessly integrate official with a server. That means we are using php implementation of a server and js implementation of a client. Uppy tus-js-client tus-php uppy.use(Tus, {endpoint: 'https://server.tus.local/files/', // your tus endpointresume: true,autoRetry: true,retryDelays: [0, 1000, 3000, 5000]}) Check out more details in and example implementation . uppy docs here Partial Uploads The Server supports and is capable of concatenating multiple uploads into a single one enabling clients to perform parallel uploads and to upload non-contiguous chunks. tus-php concatenation extension The full example of partial uploads can be found . here Final Words The itself is still in its initial stage. Some sections might change in the future. Three different implementation examples can be found in the folder. Feel free to try and report any issues found. Pull requests and project recommendations are more than welcome. tus-php project example Happy Coding!

Resumable file upload in PHP: Handle large file uploads in an elegant way

Quickbooks Online vs. Xero and 5 Alternatives for 2023

What do Google, Facebook, Youtube, Amazon, Uber and a phone book have in common? They are — searchable lists of stuff. Google is a list of keywords mapped to the websites they appear in. Facebook is a list of profiles, posts, private messages, events and other types of information. Youtube has users, videos and comments. Amazon: merchants and items. Uber: drivers, customers and ride requests. indexes Oh, and the phone book. Young readers might not know that it was a 20th century business model where you print out a database of names matched with phone numbers and drop the heavy object into people’s mailboxes. Most online unicorns are essentially just indexes with a nice user interface and occasionally some sort of customer support. They are commonly called “ ”. platforms Strong network effects are the boon or bane of indexing, depending on whom you ask. Winner takes it all: users must join the most popular index in order to find others and be found, i.e. to get the most search results and appear in as many searches as possible. This is good for the winning company’s shareholders. “Competition is for losers”, as Peter Thiel wrote in his book “From Zero to One”. Also, it’s convenient and computationally efficient when you need to search only one index which contains everything and runs in a highly optimized data center. The downside is that these companies become central points of tremendous power — in other words, . Many of them have become necessities that our daily lives and livelihoods depend upon, yet they are not accountable to their own users. They are private companies that can quite freely favor or discriminate against whomever they like. What is your recourse when Facebook decides to suspend your account for 1 month at a critical time? single points of failure There have been to regulate online platforms akin to banks or electricity companies. Good regulation could help, but bad regulation could make things worse. Many things can go wrong when trying to solve problems by government force. Government too is a monopoly - one that you can’t even unsubscribe from when things go wrong. And how did it work out with bank regulation? It’s always safer if we can develop new technology that solves these problems without the use of force (and more ethical, one could argue). calls as public utilities What Satoshi Nakamoto wrote about banks applies to online platforms as well: “The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.” As we have already seen, such central points will inevitably be abused from the inside or outside for commercial, political or outright criminal gain, while the rest of us pay the price. Historically, printing presses, telegraph offices and railway stations have been some of the first central points seized by communist revolutionaries. Modern day authoritarians hijack search engines and social media corporations. They can be used to direct or suppress public debate and are to influence politics. globally used Some political activists demand “ ” of people they disagree with — too often successfully. Big tech companies themselves have a bias against conservatives, which they have acted upon, banning them more often than left-wing users. deplatforming admittedly arguably In 2018 Germany that obliges social media companies to censor “obviously illegal” user content within 24 hours or face penalties up to 50 million euros. Human Rights Watch the law on the grounds that it “can lead to unaccountable and overbroad censorship” and “sets a dangerous precedent for other governments”. At least Russia, Singapore, and the Philippines have cited the law as a positive example of legislation for removing “illegal” content online. France enacted a in 2019. started enforcing a law criticized similar law A topic of their own are authoritarian countries such as China, Iran, Turkey and North Korea which severely restrict the access to social media or even to the whole internet. People in those countries resort to VPNs, file sharing by or occasionally . usb sticks bluetooth mesh networks For many people, Snowden’s revelations about NSA mass surveillance programs have been the wake-up call to issues. It’s reasonable to ask if we want to share our digital lives with the big tech and subsequently the government. privacy Another concern about centralization is . What if someone at Google just messes up? What if WhatsApp servers are unreachable in an emergency? That concern can be shared regardless of your particular political bias. infrastructure security Decentralize indexing. Take out the middleman. It gets a bit more technical here. How do we make it right? Bitcoin is a proven decentralized alternative to central banks and money transmitters. We no longer have the situation where Alice wants to send money to Bob via middleman Carl, but Dave prevents it by pressuring Carl. Alice doesn’t need anyone’s permission to send her own bitcoins to Bob. Now we just need to make bitcoin more convenient for everyday use and . hodl Bitcoin and other decentralized are all about state management: how to achieve a consensus on the ledger’s balances without asking a central authority. Bitcoin presented a novel solution to the problem: — or more specifically, . Every full bitcoin node replicates a chain of transaction blocks, and the valid version of the chain stamped by the most computing power (proof of work) is considered as the consensus. ledgers blockchain proof of work However, . For example, : you don’t need or want slow and expensive perfect synchronization with everyone in the world. Eventual consistency is sufficient and can be achieved with : systems that don’t even need an internet access — just occasional contact with peers. Examples of such systems are , and . decentralized indexes face a different set of technical challenges and tradeoffs blockchain is not the right tool for social media conflict-free replicated data types Gun Automerge OrbitDB — — CAP theorem: Consistency, Availability and Partition-tolerance choose two. In a decentralized system one of the two must be partition-tolerance network failures do happen. When network failures inevitably happen, you need to choose between availability and consistency of state. In case of a trustless ledger, it may be better to sacrifice availability and stop transactions in order to prevent double-spending. Social networks and many other applications might do fine without strong consistency, i.e. everyone always having the same dataset. The content you post offline can be synchronized later. Even bank ATMs choose A over C, since the benefits outweigh the risks (as explained in this excellent on CAP). article Another challenge is . You don’t want spam in your social media feed. You want search results to actually contain the searched words. When the index is not run by a single trusted entity, you can use a to filter out users and peers that produce spam or other unwanted content - all without giving power to central moderators. how to make sure that the data you receive from peers is relevant or valid web of trust Bittorrent solves this somewhat similarly, exchanging file parts with peers on tit-for-tat basis, rewarding peers for co-operation. You can see your download start slowly and then speed up as other downloading peers see that you are giving back. According to a report by Sandvine, bittorrent traffic accounted for over 50% of upstream broadband traffic in North America in 2011. Sharing of static files in a peer-to-peer network is old and proven technology. However, — big dynamic datasets — . Centralized torrent indexes are the single point of failure that governments, defending billion-dollar corporate interests, have heavy-handedly cracked down upon - most famously and more recently . maintaining and querying decentralized indexes is easier said than done The Pirate Bay KickassTorrents takes torrent indexing in a more decentralized direction. While the index is still centrally maintained, it is distributed via which makes finding its maintainer or preventing its distribution more difficult. The index maintainer could even hide behind Tor to prevent detection by traffic analysis. Torrent Paradise IPFS is a fairly popular IPFS-based project that lets merchants index their own products. , founded in 2006, is a fully decentralized web search application. Both are based on (DHT), the same technology that bittorrent uses for peer finding. OpenBazaar YaCy distributed hash tables is an interesting offline-first mobile application that can synchronize over bluetooth, wifi or remote servers. It is based on the Scuttlebutt feed synchronization system, which already has hundreds of active users. Manyverse I have been working on , . Interface-wise it’s not too different from some existing social media — you can post text, photos, videos, audio or other types of files into your feed. Iris a social networking application that stores everything on its users’ devices and connects to peers directly You can have end-to-end encrypted private chats and get mobile or desktop notifications. Users give each other trust ratings to form a web of trust — a concept that has been used in public key infrastructure since the 90s. Trust ratings are functionally not too different from adding a friend or following someone. Iris browser application . Also available for desktop , mobile and as a library . Iris web of trust works both on the software level and the user level. On the software level it is used to manage peer connections and prioritize storage space: friends connect to each other and replicate each other’s content. On the user level it aims to serve as a that naturally exists in tribes and villages, reducing the need for a and facilitating the . socially scalable version of the system of trust centralized justice system gift economy Web of trust helps filter out spam and other unwanted content without entrusting the power to a central moderator. Instead of a single moderator, you have multiple “moderators” whom you can choose and whose collective decisions you can override. , since your messages are only shown to people whose WoT you are in. It makes trolling, fake news and other propaganda campaigns more difficult Based on (“identity verifications”) from your WoT, such as domain names, email addresses, phone numbers, social media handles or CA certificates. Similarly to or Namecoin, it fulfills all three properties of Zooko’s triangle outlined in . attestations Iris maps natural names to public keys and other identifiers, providing a decentralized alternative to digital identity providers Petnames Names: Decentralized, Secure, Human-Meaningful: Choose Two Unlike Namecoin addresses or other global names, Iris names are not globally unique: there can be multiple people named John Smith. When searching for a name, you get a dropdown list of results ordered by their WoT distance, along with avatars and other human-meaningful attributes that are attested by your WoT. Iris doesn’t have a globally shared state. Instead, what you see depends on what your WoT says. It could be even used to maintain a shared conception of borders, countries and properties. Instead of Google , the borders and names you see on a map would depend on what your WoT has attested to. Good for local sovereignty advocates. Use together with public polls. playing the geopolitical moderator uncensorable Ideally, Iris users would have device-based private keys that share access to the same private data. Losing one key doesn’t matter, and the other keys can be used to invalidate the lost one. If you lose all your keys, you can just ask your WoT to attest a new key to your identity. After enough verifications, other users can fetch the private chats with your old key and re-encrypt them to the new key. Your non-shared private data would be lost though. That could be avoided with yet another key recovery option: , which allows e.g. 3 out of 5 recovery shards stored by friends to restore your private key. Shamir’s Secret Sharing End-to-end encrypted private chat in the Iris mobile app . The strategy is to start with private messaging, since it doesn’t require the same critical mass as public messaging. Iris outsources storage and networking to Gun, the aforementioned CRDT system. With storage adapters it provides offline-first eventually consistent data synchronization between all kinds of storages, such as RAM, file system, local area network peers (multicast), websocket servers or remote WebRTC peers. With a bluetooth adapter you could use it in an ad hoc mesh network where peers don’t even need to be connected all the time - very censorship-resistant. Iris users maintain their of Message and Contact objects. These are synchronized and queried over Gun. When you search for messages or contacts, other indexes in your WoT are also queried. That is . indexes web of trust based decentralized indexing This works using Gun's simple API: # open our own index (read & write permissions)
user = gun.user()
user.auth(keypair)
user.get( ).get(indexKey).put(message)
user.get( , params).on( doSomething(msg))
user.get( )...

# open someone messages 'messages' 'messages' => msg 'contacts' else 's index (read-only)
user = gun.user(publicKey)
user.get(' ', params).on(...) like Google, Amazon, Uber etc. The same paradigm could be used to store and retrieve other kinds of objects and build all kinds of decentralized alternatives to platforms Sharding, replication factor, algorithms for efficient querying of peers and other optimizations are yet to be explored. Perhaps a DHT between trusted peers could be used. The optimal division of labor between local devices and servers (super-peers) needs further research: you want it to work offline or in a mesh network (to some extent), but also to be able to utilize the power of data centers. Servers and efficient data centers have their place even in a system where the data model, storage and networking support decentralization. You could still have companies that maintain large indexes: they would just be interoperable with other actors in the network. The question is how to find the right balance between them. In order to truly compete with centralized platforms, . Iris and the other presented solutions are not quite there yet. Bittorrent does a great job with download speeds, but has no integrated content indexing and search like we’re used to on Netflix, Steam or Spotify. The others typically have performance or scalability issues. On the other hand, we can already boast offline-first capabilities and ease of signup unlike Facebook and the others. Not to mention the sheer ecstatic feeling of self-sovereignty. decentralized applications must provide user experience as good as or even better than what we are used to Iris logo: rainbow colored eye in a speech bubble. If you’re enthusiastic about something that nobody else seems to get, odds are that you are chasing a rainbow (and Iris happens to be the Greek goddess of the rainbow). But sometimes you are right. In 2009 I emailed Satoshi Nakamoto and offered to help however I could with Bitcoin. After that it would take years before bitcoin’s success eventually convinced people to start taking it seriously. I have been similarly enthusiastic about the ideas behind Iris for years, but lacked the marketing skills to promote them. I believe that code speaks louder than words though: bitcoin wouldn’t have gotten off the ground with only the whitepaper and no reference implementation to prove it. Iris software is getting there, but progress is slow when you’re working on a complex system by yourself, using experimental building blocks that have changed many times along the way. If you liked the analysis or the proposed solution, please share this article or check out for more contribution options. If you have a better idea on how to decentralize indexing or otherwise make us less dependent on corporate online platforms, please let us know. The world needs it! Iris on GitHub

How To Fix Everything That's Wrong With the Internet

Abstract Digital Key in Primary Music Education It is well-known the difficulties in perception of any information, including musical one, cause strain of the main functional systems in the child’s body. Statistics and practice show that period of learning with standard music grammar is pulled for several years. At early stage of learning up to thirty percent of children lose their interest to the music subject and leave study. This situation is explained by the excessive load arising at the first contact of the child with a complex format learning the piano. In order to protect the health of parents and children in response to COVID -19 our  Neuromusic Lab proposes to replace face-to-face music training with distance deep learning.We would like to share a technological resource that can both reduce the risk of severe disease and simplify the methods of initial music training. Numeric Cognition 3345. 5432. 1123. 3020. 3345. 5432. 1123. 2010.  Ode to Joy Ludvig van Bethoven 3330. 3330. 3512. 3000. 4444. 4333. 3223. 2050. 3330. 3330. 3512. 3000. 4444. 4333. 3554. 2010.  Jingle Bells Formatted lessons give an equally valuable positive result, regardless of the platform, both interactive and online lesson. The above should not be understood as a rejection of generally accepted music teaching  in the classrooms but to protect the health of children and adolescents, online learning technology will be effective and successful. The future of effective learning is combined with pattern recognition technology. Digital Key Technology is designed to deepen our understanding of cognitive abilities and improve the child's memory capabilities. The Project " Reflection " is aimed at studying the somatosensory integration of nerve signals in the main functional systems of the child’s organism : the central nervous system, auditory , muscular , visual , using electrophysiology measurement techniques - ENG, EMG, EEG, Audiometry. Method EEG allows to research the difference of the integrated synaptic signals , to make the comparative diagrams of dynamics of initiated spikes while perception music characters and digital patterns, plus the time of fatigue of synaptic structures and cells - neurons of cortex is determined . Method  ENG - EMG completes one another, joints the visual analyzer with the neuro-motor function of fingers  and proves , from scientific point of view , the development of muscular fatigue in hands depending on the quantity of eyeballs’ fluctuations. Method Audiometry allows to research the increment of sensitivity to the functional sounds ( pure-tone ,high - low pitched, brain waves, beta range) plus the behavioral audiometry. Innovative technology raises the topic of the use of the Digital Key in Primary Music Education and the Music Industry. Read more: https://www.linkedin.com/pulse/digital-key-initial-music-education-stepanov-sergey/

Distant Deep Teaching 

Learn how to automate away as much maintenance as possible using Renovate, Travis CI, and CodeCov Last year I wrote a five part series of articles that built . It demonstrated how to use , automatically , achieve , explored using , and covered . a React boilerplate using Parcel streaming server side rendering enforce code quality 100% code coverage Docker for development multi-stage Dockerfiles for production Unfortunately, as time has passed, the boilerplate has begun to get stale. Some of the libraries I chose have changed their APIs, and as a result people following the tutorials as written have encountered some errors as they are getting later versions when following along and typing . npm i It's come time to update this boilerplate, but in my typical fashion, I've decided to turn it into a learning experience by showing how to let bots do the heavy lifting for me. In this article we will use a particularly useful bot called " " which will keep track of the project's dependencies and make Pull Requests every time an update needs to be made. Renovate was recently acquired by WhiteSource and was previously named RenovateBot. Because we have a bunch of automated tests and code quality enforcement at each step of the way we should be able to quickly see if everything is still passing or if a particular update causes any breaks. Renovate At the end, we will also explore what extra steps could be taken to give us even more confidence in each change. With that being said, here is the repo we will be renovating: https://github.com/patrickleet/streaming-ssr-react-styled-components Let's get started. Step 1: Enable Renovate My repository is on Github, and therefore we will head over to the Github Marketplace where we can enable the . According to their website, there is also support for GitLab, as well as a tool that can be run with some manual set up in other situations such as On Premises. I've been using Renovate Bot for over a year now, with great success, but I've only tried the GitHub version. Renovate Application Developer time is expensive, best to let bots do as much as possible! The setup is pretty straightforward, just press "Install it for free" down at the bottom. If you need more help, I defer to checking , as the process may change after this article is written. their website Step 2: Configure Renovate Once Renovate has been installed, you can configure it from the "Settings" page of your account or organization in the "Applications" tab. You'll have the choice to enable it for all of your repositories, or select repositories. Seems how I have a lot of repos, I decided to only enable it for certain ones. This choice is up to you. Shortly after giving Renovate access to your repository you should receive a Pull Request titled "Configure Renovate" which will add a file named renovate.json to your project. If we take a look inside we can see that the config is pretty simple, but allows for . lots of customization { : [ ]
} "extends" "config:base" Some customizations you may want to make are things like enabling automerge if you have a high enough confidence in your automated test coverage and code quality enforcement. This will allow renovate to automatically update packages for you if all checks pass. It's also possible to only enable automerge for minor versions, just devDependencies and much more. I'll leave it to you to look through all of the configuration options and decide what is best for your team and project. In this , Renovate will detail which package files it has detected and what Pull Requests with what updates you can expect to see once it's been merged. initial Pull Request One of the reason's I switched from using Greenkeeper to Renovate is it's support for much more than Node.js packages. For our purposes, it will also keep Dockerfiles, , and Helm chart files up to date, but also supports much more such as Gradle. The full list can be found in the project's documentation. docker-compose To finish the configuring your repository for Renovate simply merge the Pull Request. Step 3: Automatically Run Tests For Every Pull Request with Travis CI In the previous articles we set up a bunch of Code Quality enforcement as well as configured automated tests with 100% code coverage. Before we start merging changes that could potentially break our project, we'll want to make sure that all of these checks are run with every Pull Request. There are many options to do this, but the quickest and easiest for open source projects is probably Travis CI. Enabling Travis CI is just as easy as Renovate, just head on over to the Application in the Github Marketplace, select the free "Open Source" version, and press Install. Again, you'll have the option to enable it for all repositories, or select repositories. I'm again choosing to limit it to just my selected repos. In order for Travis to kick in, we'll need to add a file to the project with the appropriate settings. The minimum we will need is to set the language of the project. Supported languages can be found . .travis.yml in their docs language: node_js Here's the PR adding the file to the project: https://github.com/patrickleet/streaming-ssr-react-styled-components/pull/10 Travis notices right away and starts running our builds. By default, Travis CI does not know what version of Node we are supposed to be running, however, and uses the default version of which is probably about a decade old by now. We will need to make a small update to our config file to tell it what we want instead. At the time of writing this article Node 11 was the latest version, and was chosen. 0.10.48 Let's go ahead and tell Travis to run the build in Node 11, as well as the latest version 12. language: node_js node_js: - 11 - 12 Travis knows to run tests as part of its default Node.js script, and for many libraries or applications, this will be enough. This particular application, however, runs some tests against the built version that is outputted by Parcel, and for that reason, we will need to customize the script to make sure our Parcel build runs before the tests. Let's update our file again to account for this build step before the script runs. .travis.yml language: node_js node_js: - 11 - 12 before_script: - npm run build And with that, we have passing builds! Step 4: Enable Code Coverage Reporting Alright, we have passing builds, and our tests are outputting code coverage, but it's a bit hard to get at. We want to ensure that we are not losing coverage with a new PR, so it'd be really helpful if we had that information as part of the Pull Request. For this, we can use a tool called from the Github Marketplace. CodeCov Just as before, select the "Open Source" plan and press Install. Again, I've chosen to only give permission for specific repositories, as I have a lot. In order to finish setting up CodeCov we can add a couple of steps to our file. We can do this in the lifecycle step. .travis.yml after_success Here's our new file: .travis.yml language: node_js node_js: - 11 - 12 before_script: - npm run build after_success: - npm i -g codecov - codecov Now with each PR, a bot will comment with changes in coverage. Here's . the PR where CodeCov was enabled The question marks are simply because we didn't have coverage data in the master branch yet. Once this PR is merged, future report will include the difference between the PR and the master branch. Step 5: Pin Dependencies While we were setting up Travis and CodeCov, Renovate made some Pull Requests. The first of which was setting all of the dependencies to a fixed version. This eliminates the reliance on SemVer, or semantic versioning. SemVer allows a range of versions and can be useful to get minor and patch updates each time you run . Seems how we have a bot monitoring our packages for us, we will rely on it to do this work instead of SemVer. This results in more reproducible builds and less possible variance between each developer's machine. A more detailed discussion of the reasoning behind this can be found . npm install in Renovate's blog We'd like to see how each of the PRs affect test coverage and ensure they are still passing, though. Renovate is pretty smart, and can easily rebase the PR's it has made. Given enough time it will usually do so automatically, but we can help it along by clicking the checkbox in the PR's description that says "If you want to rebase/retry this PR, check this box". Within a few moments at the Travis build kicks off, and a couple of minutes later we have passing builds and tests, as well as a code coverage report showing no change in coverage - still at 100%. a rebase has been performed Pinning dependencies is a rather safe operation, as all that is happening is the explicit versions that are already installed in the package-lock.json file are being reflected in package.json. We can also see all of the tests are still passing, and code coverage has not been affected. Let's merge it! Step 6: Testing our Dockerfiles If you're paying close attention, you've noticed that we are testing our Node application, but not our Dockerfiles. In the previous article we created a process to run and test our Dockerfiles but we are not taking advantage of that process in Travis. The problem is that Renovate will make PRs to keep our Dockerfile's up to date, and if we don't automatically run them we may miss something that works on Travis but not in the container. Let's fix that. To do so we can add a new section to our file called jobs that define the docker build jobs. .travis.yml language: node_js node_js: - 11 - 12 before_script: - npm run build after_success: - npm i -g codecov - codecov jobs: include: - services: - docker script: - docker build . -t ssr - services: - docker script: - docker build . -f nginx/Dockerfile -t nginx We have two Dockerfiles, because this project specifically demonstrates two different alternatives - one with SSR, and one with Nginx. Therefore, we have two new jobs defined. In the Travis UI we can see that we now have four jobs – the original Node 11 and Node 12 builds, as well as two more that run the commands. docker build Clicking inside of " " and " " we can see the output for each of the docker build commands indicating their success. 25.3 25.4 Step 7: Package updates With the pinned dependencies out of the way, we will start receiving Pull Requests for our other packages that need updating. The updates will either be a minor version update, which are generally pretty safe so long as the package author is using semver appropriately, or major version updates, which should receive a bit more scrutiny. Make sure if you had any open before the Travis and CodeCov changes you trigger a rebase of those branches. We'll also get updates to our Dockerfiles, and thanks to the last step, we know those are being built as well. Renovate will only make two Pull Requests per hour, and not open more than twenty total pull requests at a time. Let's take a look at the PRs I've received so far, and talk about how to handle each of them. There are five of them so far, and a range of different types of examples. and are both update to Dockerfiles, and they are both passing, including actually running the builds so we know that the updates still result in a working Dockerfile. It'd be nice to run them as well and have a preview environment created automatically for each environment, but we'll need more tools and a more complicated set up to get that. It's totally possible, and something I usually set up for my clients, but this article is getting long already. #9 #11 is a major version update. In version 1 of react-helmet-async there is a breaking change, and our 100% code coverage correctly detected that something went wrong. If automerge were enabled, this would not have made it through, exactly as planned. #12 is a major version update as well, but our build and tests are working, so we can be pretty confident we are all good here. Again, a preview environment that actually runs this build in the cloud for us would get us to that next level of confidence. We can click the down arrow next to "Release Notes" in the PRs description to take a deeper look. #14 If an author is diligent they should detail what breaking change warranted the major version bump. Unfortunately in this case, the author did not provide this information. Not knowing what the reason was increases the risk, and decreases developer confidence. If you're a library author, I strongly suggest using tools like commitizen and semantic-release to make sure users of your package are kept informed. I wrote up a process of how to do this in a previous article: . These 6 essential tools will release, version, and maintain your NPM modules for you Lastly, is a minor version update, but demonstrates Renovate's ability to group related packages. Some libraries choose to version all components of the library together. Renovate contains some preset, popular libraries in this manner, such as babel as we are seeing here. #16 I like living on the wild side, and hate clicking buttons that a bot could click for me, so instead of going through and merging all of these, I'm just gonna go ahead and enable automerge for Renovate. I'm pretty confident that the 100% coverage of the tests do a good job in catching breaking changes as they have demonstrated with PR #12. To enable automerge, update your file like so: renovate.json { : [ ], : } "extends" "config:base" "automerge" true Here's . the PR that enables automerge However, without preview environments, there's too much that could potentially go wrong with major versions. Let's make one more update so major versions will require a manual review and merge: { : [ ], : , : { : }
} "extends" "config:base" "automerge" true "major" "automerge" false Automerge will take some time to kick in, so I'll let it do it's thing for awhile. While my bots get to work, let's take a look at the failing PR and see if we can find out what went wrong there. Step 8: Investigating failing builds The failing build is caused by updating the library "react-helmet-async" to from version 0.2.0 to 1.0.0. Unfortunately, when we expand the release notes, the library author did not give us any information about what the breaking change may have been. Renovate does allow us to click through via the "Compare Source" link to see what commits and code changes have occurred though, and of course, looking at the failing tests may give show us what went wrong. From clicking we can see that the breaking change is moving the default export to a named export. Compare Source for V1.0.0 The error message in the tests was pretty unclear, so thankfully looking at the "Compare Source" link helped us find the change pretty quickly. To fix it, I'm going to go ahead and check out the branch that Renovate made and simply add a new commit to it which changes the import to use the new named import. Here's . the commit containing the fix And with that, our tests are now passing again. Step 9: Testing major version changes is a great example of why we need to test major version changes. If we had a preview environment we'd find that although the tests are all passing, there are run time errors related to API changes. Seems how we do not, I had to discover this by checking out the branch that renovate created and running it manually. PR #14 react-imported-component The library has changed in order to be inline with React Suspense and React.lazy. Looking through the docs shows us how to refactor to use the new API. If you're interested, . the diff can be seen here Conclusion Developer time is expensive, and maintenance is important as package updates often contain security fixes. Staying up to date will make sure any known bugs in the packages you are using get fixed as the author makes updates. Due to the time required to keep everything up to date, these small updates often fall by the wayside and over the months and years your projects can get painfully out of date. By employing a set of bots to do the heavy lifting for you, it's much easier to keep everything up to date. That's all for now! Happy coding! Check out the other articles in this series! This was part 6. Part 1: Move over Next.js and Webpack Part 2: A Better Way to Develop Node.js with Docker Part 3: Enforcing Code Quality for Node.js Part 4: The 100% Code Coverage Myth Part 5: A Tale of Two (Docker Multi-Stage Build) Layers Interested in going deeper, and getting things like Preview Environments on every Pull Request? In my new masterclass, Cloud Native Entrepreneur, you'll do just that by engineering end-to-end marketing systems with microservice backends and running them in production with Kubernetes! All while learning marketing and entrepreneurship along the way! Check my Hackernoon profile to find how to register for a free info session! Best, Patrick Lee Scott

Bring In The Bots, And Let Them Maintain Our Code!

This post require to know how write and read the .yaml syntaxe only : easy ! ;) What we need ? A terminal with php on your local machine A git repository for your project What we use ? automate ! This is the official website of automate : https://automate-deployer.com/ Automate It’s time to start ! First, the file .automate.yml First, add the file at the root of your project (not the public directory), write this lines : .automate.yml repository: :romaricp/kit-starter-symfony-4-docker.gitplatforms:development:default_branch: mastermax_releases: 2servers:dddv-server:host: 10.128.12.12user: devpassword: %dev_password%path: /home/wwwroot/sf4preprod:default_branch: preprodmax_releases: 2servers:pddv-server:host: 10.128.12.13user: devpassword: %preprod_password%path: /home/wwwroot/sf4shared_files:- .envshared_folders:- public/uploadon_deploy:- "composer install"- "setfacl -R -m u:www-data:rwX -m u:`whoami`:rwX var"- "setfacl -dR -m u:www-data:rwX -m u:`whoami`:rwX var"- "php bin/console c:c --env=prod --no-debug"post_deploy:- "php bin/console doctrine:schema:update --force"- "php bin/console cache:war --no-debug" git@github.com Okay so what we have write here ? It’s just setting, not coding ;) repository: :romaricp/kit-starter-symfony-4-docker.git git@github.com Here, we just wrote the address of your project, for example here a sample project with Symfony4. platforms:development:default_branch: mastermax_releases: 2servers:dddv-server:host: 10.128.12.12user: devpassword: %dev_password%path: /home/wwwroot/sf4preprod:default_branch: preprodmax_releases: 2servers:pddv-server:host: 10.128.12.13user: devpassword: %preprod_password%path: /home/wwwroot/sf4 Here, we defined all servers we want to deploy our project. So as you can see, 2 servers are defined : and one. development preproduction For each server we defined which git branch is used via ; so for the server I want to use the branch and for the server I want to use the branch. default_branch development master preprod preprod We have to defined how many maximum releases we want to stock on each server. 2 seems good because if you get some bug after a new deployment you can rollback with one command, we will see later. servers:pddv-server:host: 10.128.12.13user: devpassword: %preprod_password%path: /home/wwwroot/sf4 Here, we defined all servers by platform, In this case we have just one server / platform but you can easely add 2 or 3 servers to deploy your project. For each server you have to define : Host User (with ssh access) The path of you project on the remote server For the password, it’s not a good practice to write this one here in this file, so that’s why we are using each side, because when you will start the deployment the terminal will ask you to enter the right password. % shared_files:- .env Here, we defined all files shared for all releases, in this case this file is for Symfony which contains all the necessary environment variables. So no matter which release is current there is just one config file for all my releases ! environment shared_folders:- public/upload Here, same story with folders. We defined all folders that we need for all releases. The best example is the upload directory. on_deploy:- "composer install"- "php bin/console c:c --env=prod --no-debug"post_deploy:- "php bin/console doctrine:schema:update --force"- "php bin/console cache:war --no-debug" Here, it’s the list of commands lines that your project need to be deploy perfectly. There are 3 events availables with automate : , and all are well explain here : pre_deploy on_deploy post_deploy https://automate-deployer.com/ doc So now your .automate.yml file is ready ! Second, install the automate.phar Go to your root path of project cd /your/path/project You can download the latest version of Automate with the following command: curl -LSs https:// Now you should get something like that : Sample with Symfony4 project It’s time to deploy ! Go to your root path of project and launch automate ! cd /your/path/project start the deployment Enter the and enjoy the show ! ;) dev_password You should get something like that : End point of the deployment What happen to our server ? Well if you go to our server, we should get something like that : our development server remote current directory is a symbolic link to the lastest release releases directory contain all last releases (depend the max_releases number you set in the .automate.yml file) shared directory contain all folders shared between every releases If we go to the you can see : shared directory the shared directory Which contain the “real” folders and files. On the other hand if we go to the current directory you can see : The file is a symbolic link to the real file which is in the shared directory. .env .env So as you can see, we deployed without a single line of code ! Automate is very easy to use and to set. Automate has a lot of plugins by default, you can see all of this to the official documentation : https://automate-deployer.com/ doc To conclude, we can now imagine to use automate and gitlab with an automatic deployment on each merge request ! ;) Thanks to & for rereading. :) Solène Louvrier Nicolas Legendre

How to deploy on multiple servers a project without a single line of code!

Get to know RemotiveBroker’s gRPC API and how it simplifies prototyping, building & testing automotive software. Build software the way you want and in the programming language of your choice. We make things easier with a Python wrapper and the gRPC stubs available in a public repo on our GitHub. Get stuff done with our gRPC API Want to make a quick prototype using Python? Interested in Rust? The RemotiveBroker gRPC API can be used to read and write vehicle signal data in your language of choice. This means that you can use the tools you prefer to quickly build applications that depend on real vehicle signal data. Given a simple configuration and a signal database file, you can get to work right away with recorded data or inside a physical vehicle with live data. Use the same API regardless if you are working with recorded or live data, write your application once and test it on your desktop and inside a vehicle! You can reuse previously recorded drive cycles, e.g. in a deterministic ECU testing setup or when prototyping graphical user interfaces. Once you are satisfied with your work you can, in a true shift-left spirit, bring it to a test rig or physical vehicle knowing that the code has been tested. Paired with our collaboration platform, RemotiveCloud, you can quickly scale up your development efforts with multiple virtualized RemotiveBrokers! Get started with three lines of code Start a RemotiveBroker with three lines of code: $ git clone https://github.com/remotivelabs/remotivebroker-bootstrap.git
$ cd remotivebroker-bootstrap
$ docker-compose up -d Try our free 3-minute demo or check out some of our stuff on Github, e.g the APIs, simple samples, ProtoPie integration) and go to the repo for running the bootstrap RemotiveBroker on your desktop. What is a RemotiveBroker? The RemotiveBroker is a flexible developer tool that fit into most setups. it exposes vehicle signal data via a pub/sub gRPC API. We support the most common vehicle networks like CAN, Flexray, LIN, and Automotive Ethernet – enabled by .dbx, .xml (fibex), .ldf and .arxml. We also proved E2E Protection. Make it even easier with API wrappers and gRPC stubs We have a public repo for our wrappers and stubs. Anyone is welcome to submit a pull request with a wrapper in their favorite language, get started with our gRPC proto files. Our ambition is to have wrappers and stubs/clients available for everyone. Advantages of gRPC Given a simple configuration, the RemotiveBroker will expose a gRPC API that puts you in control. With the broad language support that gRPC has you can use what you prefer, e.g Node.js, Ruby, C# or Kotlin. gRPC leverages HTTP/2 and a binary message format, this helps to reduce network bandwidth and decrease latency. This allows our RemotiveBroker to send large amounts of data in real-time, like in the case of high-speed CAN & CAN-FD or FlexRay. Python wrapper We have a Python wrapper API for a subset of the RemotiveBroker API to make it even easier to build applications. It is also available for easy installation through the Python Package Index. This wrapper API makes it easier to perform common operations like connecting to a RemotiveBroker and setting up vehicle signal data subscriptions. Connect to a RemotiveBroker and set up a signal subscription: # Connect to RemotiveBroker
client = Client()
client.on_connect = lambda c: print(f"Yay! - connected as {c.client_id} to {c.url}")
client.on_signals = lambda signals: print(signals.to_json())
client.connect(url="http://localhost:50051")

subscription = client.subscribe(
signal_names=["Vehicle.Speed"],
namespaces=["vss"],
changed_values_only=False) Typescript and Javascript stubs/clients Since we are working with gRPC-web in our web clients, we have both Typescript and Javascript stubs/clients available for grpc-web. It is also available via npm/yarn. While not as useful as a proper wrapper API, the stubs/clients are required when working with gRPC. However, just looking at the stubs is helpful when exploring the API. Subscribe to frame frequency distribution: // Setup request
const config = new FramesDistributionConfig()
const namespace = new NameSpace()namespace.setName(namespaceName)
config.setNamespace(namespace)

// Subscribe
this._frameDistributionStream =  
this._networkServiceClient.subscribeToFramesDistribution(config) Our tooling and APIs are constantly evolving. Follow us on GitHub and LinkedIn to not miss out on more helpful developer content. If you have wishes or thoughts for what we should develop next don’t be a stranger! Get to know RemotiveBroker’s gRPC API and how it simplifies prototyping, building & testing automotive software. Build software the way you want and in the programming language of your choice. We make things easier with a Python wrapper and the gRPC stubs available in a public repo on our GitHub. programming language Get stuff done with our gRPC API Want to make a quick prototype using Python? Interested in Rust? The RemotiveBroker gRPC API can be used to read and write vehicle signal data in your language of choice. This means that you can use the tools you prefer to quickly build applications that depend on real vehicle signal data. Given a simple configuration and a signal database file, you can get to work right away with recorded data or inside a physical vehicle with live data. RemotiveBroker Use the same API regardless if you are working with recorded or live data, write your application once and test it on your desktop and inside a vehicle! You can reuse previously recorded drive cycles, e.g. in a deterministic ECU testing setup or when prototyping graphical user interfaces. Once you are satisfied with your work you can, in a true shift-left spirit, bring it to a test rig or physical vehicle knowing that the code has been tested. Paired with our collaboration platform, RemotiveCloud , you can quickly scale up your development efforts with multiple virtualized RemotiveBrokers! RemotiveCloud Get started with three lines of code Get started with three lines of code Start a RemotiveBroker with three lines of code: $ git clone https://github.com/remotivelabs/remotivebroker-bootstrap.git
$ cd remotivebroker-bootstrap
$ docker-compose up -d $ git clone https://github.com/remotivelabs/remotivebroker-bootstrap.git
$ cd remotivebroker-bootstrap
$ docker-compose up -d Try our free 3-minute demo or check out some of our stuff on Github, e.g the APIs , simple samples , ProtoPie integration ) and go to the repo for running the bootstrap RemotiveBroker on your desktop . free 3-minute demo APIs simple samples ProtoPie integration bootstrap RemotiveBroker on your desktop What is a RemotiveBroker? What is a RemotiveBroker? The RemotiveBroker is a flexible developer tool that fit into most setups. it exposes vehicle signal data via a pub/sub gRPC API. We support the most common vehicle networks like CAN, Flexray, LIN, and Automotive Ethernet – enabled by .dbx, .xml (fibex), .ldf and .arxml. We also proved E2E Protection. Make it even easier with API wrappers and gRPC stubs Make it even easier with API wrappers and gRPC stubs We have a public repo for our wrappers and stubs. Anyone is welcome to submit a pull request with a wrapper in their favorite language, get started with our gRPC proto files. Our ambition is to have wrappers and stubs/clients available for everyone. public repo Advantages of gRPC Advantages of gRPC Given a simple configuration, the RemotiveBroker will expose a gRPC API that puts you in control. With the broad language support that gRPC has you can use what you prefer, e.g Node.js, Ruby, C# or Kotlin. gRPC leverages HTTP/2 and a binary message format, this helps to reduce network bandwidth and decrease latency. This allows our RemotiveBroker to send large amounts of data in real-time, like in the case of high-speed CAN & CAN-FD or FlexRay. Python wrapper Python wrapper We have a Python wrapper API for a subset of the RemotiveBroker API to make it even easier to build applications. It is also available for easy installation through the Python Package Index. This wrapper API makes it easier to perform common operations like connecting to a RemotiveBroker and setting up vehicle signal data subscriptions. RemotiveBroker Python Package Index. Connect to a RemotiveBroker and set up a signal subscription: Connect to a RemotiveBroker and set up a signal subscription: # Connect to RemotiveBroker
client = Client()
client.on_connect = lambda c: print(f"Yay! - connected as {c.client_id} to {c.url}")
client.on_signals = lambda signals: print(signals.to_json())
client.connect(url="http://localhost:50051")

subscription = client.subscribe(
signal_names=["Vehicle.Speed"],
namespaces=["vss"],
changed_values_only=False) # Connect to RemotiveBroker
client = Client()
client.on_connect = lambda c: print(f"Yay! - connected as {c.client_id} to {c.url}")
client.on_signals = lambda signals: print(signals.to_json())
client.connect(url="http://localhost:50051")

subscription = client.subscribe(
signal_names=["Vehicle.Speed"],
namespaces=["vss"],
changed_values_only=False) Typescript and Javascript stubs/clients Typescript and Javascript stubs/clients Since we are working with gRPC-web in our web clients, we have both Typescript and Javascript stubs/clients available for grpc-web. It is also available via npm/yarn . While not as useful as a proper wrapper API, the stubs/clients are required when working with gRPC. However, just looking at the stubs is helpful when exploring the API. npm/yarn Subscribe to frame frequency distribution: Subscribe to frame frequency distribution: // Setup request
const config = new FramesDistributionConfig()
const namespace = new NameSpace()namespace.setName(namespaceName)
config.setNamespace(namespace)

// Subscribe
this._frameDistributionStream =  
this._networkServiceClient.subscribeToFramesDistribution(config) // Setup request
const config = new FramesDistributionConfig()
const namespace = new NameSpace()namespace.setName(namespaceName)
config.setNamespace(namespace)

// Subscribe
this._frameDistributionStream =  
this._networkServiceClient.subscribeToFramesDistribution(config) Our tooling and APIs are constantly evolving. Follow us on GitHub and LinkedIn to not miss out on more helpful developer content. GitHub LinkedIn If you have wishes or thoughts for what we should develop next don’t be a stranger!

AUTOMETRY

autometry.io

-- employees

Since n.d.

COMPANY RANKING

AUTOMETRY

EVERGREEN INDEX #838

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

Autometry WIKI

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

AUTOMETRY

autometry.io

-- employees

Since n.d.

COMPANY RANKING

AUTOMETRY

EVERGREEN INDEX #838

RELATED COMPANIESRANK

STORIES ABOUT AUTOMETRY

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

Autometry WIKI

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