Your website will be accessible with . To access it with do this three extra steps: http https with the AWS Certificate Manager for your domain Create an certificate for your "root" S3 bucket. Associate the certificate to it Create an AWS CloudFront distribution Point the record of your apex domain to the new CloudFront distribution ALIAS How to Point a Naked Domain - Not Registered with Route 53 - to an AWS S3 Hosted Static Website So people can access your website through example.com instead of www.example.com . In this post, we're going to connect an with an AWS S3 hosted website. The naked domain is bought in a domain name registrar other than AWS Route 53. In this case . apex domain OVH For other registrars the steps are similar. Apex domains, generally, cannot make use of records. Allowed are A or records, pointing to static IPs. This makes it harder to use our naked domain for our website: . This is because of the dynamic nature of AWS S3 instances. They expose a subdomain endpoint, so they can route the internal traffic with freedom. CNAME AAAA example.com Let's start. Copy your current zone file , go to: , and reduce the (Time to Live). The authoritative name servers cache will expire faster now. This is good because we're going to change the (Name Server) records. Log in to your OVH account Domains > DNS zone TTL NS Now click on: , and copy your RRs (Resource Records). DNS zone > Change in text format It should look like: @ dns18.ovh.net. tech.ovh.net. ( ) dns18.ovh.net. ns18.ovh.net. mx3.mail.ovh.net. mx1.mail.ovh.net. mx2.mail.ovh.net. ??? ??? " |www.rubenbelow.com" "v=spf1 include:mx.ovh.com ~all"
_autodiscover._tcp mailconfig.ovh.net.
_imaps._tcp ssl0.ovh.net.
_submission._tcp ssl0.ovh.net.
autoconfig mailconfig.ovh.net.
autodiscover mailconfig.ovh.net.
ftp rubenbelow.com.
imap ssl0.ovh.net.
mail ssl0.ovh.net.
pop3 ssl0.ovh.net.
smtp ssl0.ovh.net.
www ??? $TTL 3600 IN SOA 2019112215 86400 3600 3600000 300 IN NS IN NS IN MX 100 IN MX 1 IN MX 5 IN A IN AAAA IN TXT 1 600 IN TXT IN SRV 0 0 443 IN SRV 0 0 993 IN SRV 0 0 465 IN CNAME IN CNAME IN CNAME IN CNAME IN CNAME IN CNAME IN CNAME IN CNAME * Some values are replaced with: ??? In the next step we're going to import our entries in AWS Route 53. Before, let us delete some entries. Records to delete: dns18.ovh.net. ns18.ovh.net.
... ??? ???
...
www ??? IN NS IN NS IN A IN AAAA IN CNAME Create an AWS Route 53 Hosted Zone , go to Route 53, and click on: . As: , use the name of your apex domain: . Log in to your AWS console Create Hosted Zone Domain Name example.com Modify your DNS file SOA record Before starting with the next step we need to change the (Start of Authority) record to match the new one. SOA Change: @	IN SOA dns18 . tech . ( ) .ovh .net .ovh .net 2019112215 86400 3600 3600000 300 To the SOA record in your new Hosted Zone. The entry should be now like: @	IN SOA ns awsdns com. awsdns-hostmaster.amazon.com. -289. -36. 1 7200 900 1209600 86400 Import your DNS file into Route 53 Now that we have a fresh hosted zone we'll import the RRs we exported from OVH. Do not import the previously deleted NS , A , and AAAA records! Click on your new Hosted Zone: (you'll see a list of RRs) example.com Click on: Import Zone File Paste your previously exported records DNS Import your records DNS If you get: . Delete the mismatching from the zone file. "Error parsing zone file: One resource cannot have multiple distinct TTL values" TTL From: IN TXT 600 "v=spf1 include:mx.ovh.com ~all" To: TXT IN "v=spf1 include:mx.ovh.com ~all" Add an ALIAS record So far, so good. Now we add an record for the naked domain; pointing to our AWS S3 bucket. A ALIAS example.com It should be like this but  with an S3 bucket URL instead of a CloudFront URL Do the same now with an AAAA record. Add a CNAME record Add a record for your subdomain pointing to your apex domain: . CNAME www example.com It should be like this Get your new NS entries Get the values of your entry. We're going to use them at OVH in the next step. NS They should be like: ns- .
ns- .
ns- .
ns- . 289 .awsdns-36 .com 1715 .awsdns-22 .co .uk 1241 .awsdns-27 .org 740 .awsdns-28 .net Add your new AWS NS values to your domains registrar In your OVH account go to: DNS servers Delete the old OVH records NS Add your new AWS records NS Good to go. Troubleshooting The changes will take some time to propagate (sometimes up to 24h). We can check the state of the DNS (Domain Name Server) update on: Zonemaster MXToolBox DNS Checker If the DNS update is done but you cannot access through your computer, it could be that your ISP (Internet Service Provider) still did not update their RR cache. In this case, you should be able to . example.com access your website through a VPN Thanks for learning with this tutorial. Follow me on GitHub . If for some casual the indications did not work for you; don't mind to drop me a line with the infringing points . I'll update the post correspondingly. References Migrating DNS Migrate DNS Domain in Use How to Resolve Error in AWS Route 53 Import Zone File More Posts Welcome

DNS Migration: Forwarding an External Registered Apex Domain to an AWS S3 Bucket

Use Beta Distribution and Thompson Sampling to Beat The Multi-armed Bandit at the Casino

This interview was done for our Microservices for Startups ebook. Be sure to check it out for practical advice on microservices. Thanks to David for his time and input! David Calavera is the CTO at Netlify , a unified platform that automates your code to create high-performant, easily maintainable sites and web apps. For context, how big is your engineering team? Are you using microservices and can you provide a general overview of how you’re using them? Right now, the engineering department is formed by 10 people. In our company we also count designers and support engineers in the engineering department, but they write code a little less, in a lower capacity. They help with product design, internal tools and so on. We deploy three microservices in each node in our CDN network. Then we have what we call the delivery network, which is the combination of API servers and origin servers. We deploy two services in each of of those nodes, plus a background worker that performs asynchronous jobs. It’s a service extracted from a bigger application. We also have a build and deploy pipeline. There we basically have one service that handles everything, and it’s fairly small. So I would say that’s a microservice, but it’s just one. All those components are what we call the core service. We also have additional services, like our Identity service that were created from the beginning as microservices. They run independently in a Kubernetes cluster. Did you start with a monolith and later adopt microservices? We started with a decoupled architecture. They weren’t microservices per se, they were bigger services. For example, the two microservices services we deploy in delivery network between API and Origin servers now were one service before. Same happens in the CDN layer, we started the CDN layer with one service running on the edge nodes and we extracted some of the logic from that bigger service into smaller microservices. How did you approach the topic of Microservices as a team/engineering organization? Was there discussion on aligning around what a Microservice is? When we try to decide if something should live in a microservice or inside a service that already exists, the first question that we ask ourselves is if this something that needs to be coupled with a service that we already have or not. If not, then we ask ourselves if it’s something that we can consider a standalone that could actually live by itself if we just needed to use that service. Those are the main questions. We have learned that from experience. For example, two of the services that we have at the edge node are very complementary. They cannot live without each other. We are currently discussing that if they need each other, we should we just have one service instead of having two. Because, at the end of the day, they talk to each other via HTTP, on localhost, but they could also be one service, and we’d avoid a network connection. Did you change the way your team(s) were organized or operated in response to adopting microservices? Yeah, definitely. Right now we have some people working full time in what we call platform, and that’s the CDN infrastructure, and the build and deploy pipeline. Other engineers work full time on the product’s API and origin servers. Depending on which of both teams you are on, you will work on one microservice or the others. Both teams work a lot together because there is some glue in the middle that actually needs to connect the platform and the product’s API. We can see people from platform implementing things in the API layer and vice versa, engineers that are working on the product and need to implement something in one of the microservices in the edge node or in the deploy pipeline. They also try to jump into those projects in different capacity, depending on what they are more comfortable with. How much freedom is there on technology choices? Did you all agree on sticking with one stack or is there flexibility to try new? How did you arrive at that decision? Even though our stack right now has pieces of Ruby, C++ and Go, we are consolidating new microservices in Go. We have a bootstrap template to start new Microservices with Go. However, as I mentioned, we use other programming languages too. The API that started the company uses Ruby on Rails. It was like the monolithic proof of concept for Netlify. We use Apache Traffic Server in the CDN network as proxy cache. It’s a big C++ service that can be extended with plugins. We built a custom plugin in C++ to handle routing and cache invalidation. Have you broken a monolithic application into smaller microservices? If so, can you take us through that process? How did you approach the task? What were some unforeseen issues and lessons learned? One of the core principles that we have when we create new microservices, or when we have to change some functionality, is that no matter what we do, it cannot impact the current production traffic, and we cannot have any downtime. The way that we usually do this is by using feature flags, circuit breakers and abstracting logic by branches. Every component knows about several features that we can enable and disable at any time. We can do that at runtime, so we don’t have to restart any service if we want to change traffic patterns in any layer of our infrastructure. We also use some libraries that allow us to detect failures early when we do these feature flag splits. Depending on the expected behavior, those libraries can retry the same request to the new service, or fall back to the original service. How do you determine service boundaries? What was that discussion like within your team? Can you give some examples? We try to make sure that what we extract into a microservice is a standalone feature or service. Something that can live by itself and has only one purpose. For instance, in the origin servers, we have a service we call Netlify Server. It has only one purpose, which is serving web content, it doesn’t do anything else. In the edge nodes, we have a service called cache control. Its only purpose is to invalidate caches. It receives messages from the network to invalidate website caches. It doesn’t do anything else. We discuss at length different implementations for the cache controller. It makes sense as a microservice, but it could also be embedded into any of the other services that we deploy at the edge. The boundaries between this service and the other two are well defined from the feature point of view, but they work together. By keeping it separated, we can also evaluate different implementations without modifying any of the other two services. How have microservices impacted your development process? Your ops and deployment processes? What were some challenges that came up and how did you solve them? Can you give some examples? We always try to work on those services in isolation when we develop them. Unless you need to test boundaries between services, you don’t need to have the full platform running on your computer. Internally, every single service has different interfaces to talk with different services. We always provide a mock implementation for those interfaces that ignores network requests, or replies to certain requests with specific responses. Something that we have found very useful is the ability to record requests and responses from real network traffic. We do this, for example, to talk with external services that we use, like NS1 or Braintree. We use an open source project called VCR for this purpose; there are implementations in different programming languages. This allows us to record request and response messages from two services connected together like they were in production and reply them for development and testing. We’re currently centralizing all deployments in different Kubernetes clusters. We still have a handful of services that we deploy with Ansible, but we’re migrating everything to a more CI/CD friendly workflow. The services that we deploy on Kubernetes use a Blue/Green deployment system with container images. This also give us more visibility inside the deployment pipeline. We send messages to a deploy channel in Slack, where people can see when a deploy happens. How have Microservices impacted the way you approach testing? What are lessons learned or advice around this? Can you give some examples? As I mentioned before, we use VCR to record real interactions between services that we can replay during testing. We record good and bad service interactions, and update those recordings periodically to guarantee nothing changes in the external services we use. We also test many things in production directly. Our services vary depending on traffic patterns, and sometimes we cannot observe behaviors outside production. We use feature flags, logs and metrics to track what we have to test with isolated traffic patterns or websites. How have Microservices impacted security and controlling access to data? I don’t think our security model has changed much since we started. We run everything over TLS, even internal services, and we don’t allow insecure connections in our production network. Every service also uses some kind of access control to allow requests to specific resources. Have you run into issues managing data consistency in a microservice architecture? No. It’s not really an issue. Right now, only our API has write access to our main database. If a service needs to write something to that database, it needs to send requests to our API. Some microservices have their own persistent data store, and their use is very localized to the service. Thanks again to David for his time and input! This interview was done for our Microservices for Startups ebook. Be sure to check it out for practical advice on microservices. . This article was originally published at buttercms.com . It’s part of an interview series for the book Microservices for Startups Sign up to get new chapters emailed to you as soon as they’re released. If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog. And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS .

Microservices for Startups: An Interview with David Calavera of Netlify

When I co-founded my last company, one of our biggest challenges was delivering an API to our customers that would stay up 100% of the time. Our product was a content management system and an API serving millions of requests per month that our customers used to integrate content into their websites. After multiple outages that nearly crippled our business, we became obsessed with eliminating single points of failure. Downtime is Fatal Our customers built websites that made an API request to us for page content during their request/response lifecycle. This meant that if their API request failed, their page likely wouldn’t render. In other words: if our API went down, our customers’ websites went down with us. This is a lesson we learned the hard way in our early days. Unreliable server hosting led to frequent intermittent outages and performance degradations that frustrated customers. A botched DNS migration led to hours of API downtime that took down dozens of customers’ websites for nearly half a day and left a large number of customers questioning whether they could continue relying on us (a handful of them left us). After this incident, we recognized that ensuring near-100% uptime was an existential issue. A significant outage in the future could lead to us losing hard-earned customers and put our business in crisis. Delivering a Global, Fast, Resilient API Avoiding failure completely is not possible–you can only do your best to reduce your chances. For example, “controlling your own fate” by running your own physical servers protects you against your hosting provider going down, but puts you in the position of having to handle security and scalability, both of which can easily take you down and be difficult to recover from. For us, keeping our API up at all times and making sure it delivered high performance across the globe was crucial. But as a smaller company, we knew we didn’t have the resources to deliver global, highly scalable performance with near-100% uptime. So we turned to someone that did: . Fastly Fastly describes itself as an “edge cloud platform powers fast, secure, and scalable digital experiences for the world’s most popular businesses”. They work with large customers including the New York Times, BuzzFeed, Pinterest, and New Relic. We put Fastly in front of our API as a cache layer so that all API requests were served via their CDN. When one of our customers updated their website content in our backend, we invalidated the API keys for the specific bits of content that were edited. Non-cached requests hit our servers but we had a ~94% hit rate because content on our customers’ websites changed infrequently relative to the number of visitors they had. This meant that even if our database or servers experienced intermittent outages, our API remained up. We wouldn’t want this, but theoretically, our servers could have gone down completely for several hours and our customers’ websites would have stayed up. Fastly’s global CDN offers another benefit to us. Many of our customers had static JavaScript websites where API requests are made from their visitors’ browsers rather than their servers. Serving API responses via Fastly’s CDN meant that our customers’ website visitors got fast load times wherever they were located. Eliminating single points of failure During the early days of our company, we dealt with two separate DNS incidents that left us scarred. In the first incident, our DNS provider at the time accidentally “cancelled” our account from their system, leading to an outage that took nearly 6 hours for us to fully recover from. Our second incident occurred when routine DNS editing led to a malfunction by our [different] DNS provider, and took nearly half a day to resolve. DNS incidents are particularly damaging because even after an issue is identified and fixed, you have to wait for various DNS servers and ISP’s to clear their caches before customers’ see the fix on their end (DNS servers also tend to ignore your TTL setting and impose their own policy). Our experiences made us extremely focused on eliminating any single point of failure across our architecture. For DNS, we switched to using multiple nameservers from different DNS providers. DNS providers often allow and encourage you to use 4–6 redundant nameservers (eg. ns1.example.com, ns2.example.com). This is great: if one fails, requests will still be resolved by the others. But since all of your nameservers are from a single company, you’re putting a lot of faith that they are going to have 100% uptime. For our application servers, we used Heroku’s monitoring and tools to make sure our performance didn’t degrade from spikes in traffic (or if Fastly went down and we suddenly needed to route all requests directly to our servers). In addition to caching our API with Fastly, we also cached our API at the application level using Memcached. This provided an additional layer of resiliency against intermittent database or server failure. auto-scaling To protect against the rare possibly of a total outage across Heroku or AWS (which Heroku runs on), we maintained a separate server and database instance running on Google Cloud that we could failover to quickly. Failure is inevitable No matter how reliable our API was, we had to accept that networks are and failures are bound to occur. We’ve all experienced trouble connecting to Wi-Fi, or had a phone call drop on us abruptly. Outages, routing problems, and other intermittent failures may be statistically unusual on the whole, but still bound to be happening all the time at some ambient background rate. unreliable To overcome this sort of inherently unreliable environment, we helped our customers build applications that would be robust in the event of failure. We built SDK’s that included features such as automatically retrying when API requests fail, or supported using a local backup such as Redis. Final Thoughts Without realizing it, many of us are building single points of failure into our stack. To build resilient, fault-tolerant systems, you have to consider all aspects of your stack and find ways to keep your service up even when one or more things fail. Liked this article? Follow me on Twitter where I share thoughts on building businesses and getting through life. Check out my latest product that sends you Slack reminders about GitHub pull requests.

Designing a Mission-Critical API Serving Millions of Requests per Month

Kris Beevers has raised over $40M in VC, sold to the most important companies in tech, and is sharing four key lessons! Four years ago, founded to deliver superior DNS and internet traffic management solutions. His previous work as a principal software architect and chief scientist equipped him to handle the technical challenges, but as a first-time CEO, he had to master the dark art of sales. In the two years since we’ve invested, NS1 has collected an amazing customer list that includes Riot Games, Dropbox, Linkedin, Yelp, Salesforce, Imgur, and The Guardian, among many others. He’s also just raised a $20M Series B1 less than a year after raising a $23M Series B based on the outstanding early success of the business, and he was willing to share some tips on how he got there. Kris Beevers NS1 Differentiate Yourself Let’s be honest, DNS is kind of invisible — most people don’t have any idea typing brings them to a treasure trove of tiny animals — it just happens. But that doesn’t mean companies built around it have to be. When Beevers was building the brand for NS1, he knew he could shine a light on this overlooked technology, and stand out from competitors, by taking calculated risks with design. He avoided the cliche network diagrams and dull color palettes preferred by his competitors and built a corporate identity that looks more like and than B2B software. how http://cuteoverload.com/ throwback Nike streetwear $2,000 Saint Laurent silk blouses worn by Kardashians This is not your typical DevOps aesthetic! The eye-popping color and minimal graphics even filtered down to the logo. “We looked at three versions of the logo with techie swoops,” he says. “But it never felt quite right until we stripped it down to a simple logo with a pink dot.” An early version of the logo that looks like a standard B2B trademark. NS1’s hot pink became a trademark, even influencing the T-shirts the team wears at trade shows. “Companies spend a lot to figure out how to brand themselves,” says Beevers. “The answer can be as obvious as walking around a conference in bright pink T-shirts.” T-shirts are an undervalued B2B marketing resource. Hunt Logos According to Beevers, the secret to high dollar B2B sales is simple. It’s also slow, grinding work that requires huge amounts of preparation, planning, and execution. The primary goal is to win high-profile customers, earn their loyalty and advocacy so that they will allow you to display their logos on your homepage, and use those trust marks to continue to earn new customers. Repeat until the IPO. Win customers, show their logos, repeat until IPO. This is a small sample of NS1’s customers. It’s simple advice to give, but incredibly challenging to implement. In the early days, founders have to tap investors, friends, and former colleagues for intros. Beevers does offer one growth hack. “At the start of a process, ask for multiple introductions to a sales target,” he says. “It’s easy to ignore one intro, even a warm one, but if they hear about your from several people they’ll feel like you’re someone they have to know.” Always Be Closing is BS “Always Be Closing” is a great mantra for a salesperson with a quota, but not customer service agent tasked with managing a high-dollar value customer. Beevers advises startups to skip upsales on customer service calls, a surprisingly prevalent B2B tactic that leads to an uptick in short-term revenue while tending to turn off customers. Used car dealer’s pressure tactics are a bad match with technically-focused clients who expect a highly consultative sales process. Customer service teams should focus on customer satisfaction and advocacy. If the customer service team learns of a need that can be filled by their organization, they refer that to a sales team, but sales should remain responsible for the revenue relationship. Nice praise to receive from a customer like Pinterest! Beevers best sales tip is to listen—with a goal to understand the potential customer’s business environment and unique technical challenges. Often, the best long-term move is helping to solve the client’s problem, even if that means introducing them to a service provider in another product category. For instance, if improved DNS or traffic management solutions aren’t the client’s most urgent problem, Beevers is happy to make an introduction to another company that can solve the customer’s pressing needs. Acts like this generate no revenue in the short term but build the foundation of a long-term relationship. How a $200 Conference Pass Led to Signing LinkedIn Signing up customers is hard, yet sometimes you get lucky. According to Beevers, the highest ROI marketing spend in NS1 history was a $200 exhibit hall pass to an O’Reilly conference. While walking the thinly-carpeted floors of this tradeshow, Beevers met a decision maker at Linkedin and laid the groundwork for what would become a company defining sale. NS1 didn’t have a team of sales reps working the floor, and there was no wining and dining of key accounts. However, Beevers was armed with a strong product and had perfected a pitch that was powerful enough to pique the interest of someone who was previously peeking at a competitor’s booth. The lesson: Kris was lucky to meet the right person at LinkedIn, like the saying goes, luck comes when opportunity meets preparation, so spare no expense when it comes to developing a compelling product and a narrative around it. If you found these tips valuable, follow us on Twitter, clap( ), and subscribe to our newsletter for more information. Need a DNS or traffic management solution? Check out NS1’s website and Twitter and this 👏 video explaining how Yelp benefits from superior DNS solutions . Seriously, if it’s good enough for Yelp, it’s probably good enough for you!

Four Lessons Learned Selling to Dropbox, Salesforce, LinkedIn & Yelp

Introduction This is the third post in my series of , the real time collaborative editing algorithm. The first and second posts were and respectively. Operational Transformation (OT) How Real-Time Collaborative Editors work? [Operational Transformation] Operational Transformation, the real time collaborative editing algorithm As mentioned in earlier posts, Operational transformation was originally born due the need of consistency maintenance in collaborative text editors. In the span of over two decades OTs have gained new capabilities (such as undo operations and group undo) and have been applied to different applications ranging from HTML/XML editing, office and even 3D digital media design tools. tools There are many established approaches that exists to operational transformation. In this post, I will walk through the different OT algorithms that are well defined and implemented. Definitions/Terms used : In the post, I explained about the two kinds of Transformation functions, i.e, Inclusion Transformation and Exclusion Transformation. These functions have two properties/preconditions which ensures OT correctness. TP1 and TP2 are the transformation/convergence properties. second For two concurrent operations O1 and O2, the transform function (T) satisfies TP1 iff O1 T(O2, O1) ≡ O2 T(O1, O2) where denotes the sequence of operations containing Oi followed by Oj and ≡ denotes the equivalence of the two operations. : TP1 is required only if the Operational Transformation system allows any two operations to be executed in different orders. TP1 : o o o Precondition of TP1 For three concurrent operations O1, O2 and O3, the transform function (T) satisfies TP2 iff T(O3, O1 T(O2, O1)) ≡ T(O3, O2 T(O1, O2)). : TP2 is required only if the OT system allows two operations O1 and O2 be IT-transformed in two different document states (or contexts). TP2 : o o Precondition of TP2 TP2 property illustration 1. dOPT — distributed OPerational Transformation The dOPT Algorithm was one of the first approaches to OT. In dOPT Algorithm, each machine has an identifier i, which could be an IP or MAC. Each machine has to maintain a state vector s with components where is the number of machines. The component store the number of changes recorded by the machine. The requests are of the form: <i, s, o, p> n n i ith i — the original site’s identifier s — the state vector of the machine which is sending o — the operation which needs to be performed p — the priority which is associated with o [ ] this is where the algorithm got wrong A transformation matrix, denoted as T, is what solves . T is a matrix, where is the number of supported operations in the group- ware system. Each entry in the matrix is a function which transforms operations into other operations and to ensure convergence dOPT requires the Transformation Property 1. conflicting operations m x m m For handling requests, the actions are based on comparisons between [sending state] and [receiving state]. If they are same i.e , is executed immediately, if is queued and executed later and if is transformed and then executed. s_i s_x s_i = s_x o s_i > s_x, o s_i < s_x, o Strengths of the algorithm : Immediate feedback for local operations. Does not require locking of resources. Relatively easy to implement due to its simple data structures. Satisfies the which is defined as_, a_ consistency property which ensures that the execution order is the same as the operations natural cause-effect order. In other words if an operation causally precedes another operation , then at every site will be executed before . precedence property, O1 O2 O1 O2 Enforces the Transformation property 1. Problems: The priority, , suggested doesn’t work great for two clients. It fails whenever an operation is concurrent with two or more dependent operations. This algorithm is distributed and have a central server. p does not 1.1. adOPTed Algorithm The shortcomings in dOPT were in the way it transformed operations. The adOPTed introduced the second transformation property [TP2] which ensures that transformation of an operation along different paths will yield the same resulting operation. The adOPTed algorithm is right in general, and solves most of the shortcomings of dOPT algorithm but which is defined as, a consistency property which ensures that the intention of an operation is preserved after a transformation. The intention of an operation, , is the effect of applying on the resource where the operation was generated. has not proved Intention Preservation property, O O Also, the intent is always . Machines have no intent, Humans do. That’s why preserving intention becomes of sufficient importance. _of the user_ 2. GOT and GOTO — Generic and Generic Optimized Operational Transformation GOT control algorithm maintains convergence nicely i.e. when the same set of operations have been executed at all sites, all copies of the document which is shared are identical. Also, it is integrated with which states that when a new operation is ready; Undo/Do/Redo Scheme O operations in (which is defined as ‘saved executed operations at each site’) which totally follow to restore the document to the state before their execution. Undo History Buffer ( HB_)_ O (the operation) Do O all operations that were undone from the HB. Redo Also, in this convergence TP2 is not a necessary condition i.e the precondition CP2/TP2 is required only if the OT systems allows two operations op1 and op2 be IT-transformed [inclusion transformation] in two different document states. Strengths of the algorithm : OT based undo is established, faster and more efficient undo based operations. is fulfilled, which is defined as, a consistency property which ensures that copies of a shared resource are identical at all sites in state of rest (i.e. ensuring that all operations are executed). Convergence property Problems : The algorithm only supports basic string operations i.e Insert/Delete. Also, correctness proof of algorithm is missing. Algorithm is the ptimized version of GOT Algorithm. The optimization takes place because of two postconditions, and to reduce the number of (Inclusion/Exclusion) transformations by adding the properties from adOPTed. GOTO O TP1 TP2 IT/ET GOTO algorithm uses the function which basically uses ET between an insert and a delete [concurrent], what basically happens is we transpose the entire history to obtain the concurrent operations when integrating a remote operation. The algorithm fulfills the convergence property, precedence property, TP1, TP2 and has better undo operations, but was . convert2HC() never theoretically proven correct for all scenarios 3. COT — Context-based Operational Transformation The COT algorithm does not use a history buffer (HB) when an operation is executed, instead it keeps track of the document state in which a operation have been executed in. So instead of a HB it has a context vector. In an OT-based collaborative editor, a document state can be uniquely characterized by the set of original operations executed so far on the document. These original operations may be executed in different orders or forms at different sites, but they must produce the same document state according to the convergence/transformation properties . Moreover, the difference between two document states can be expressed in terms of different original operations executed in these two states. Since every transformed operation must come from an original operation, is used to denote the original operation of O. org(O) A document state, denoted as , can be represented as : DS The initial Document State is represented by DS = { } After executing an operation on , the new Document State . O DS DS’ = DS ∪ { org(O) } An operation is defined by a site identifier and a number given when it is generated. This operation in turn has that contains the operation context in terms of operations that precedes it. The operations inside the context vector in turn have their own site identifiers and defining numbers. a context vector This is the main difference since COT heavily relies on every operation which is to be executed on the same document state on all locations, if the operation is executed on the same document state at all sites the result can not diverge. A context vector, denoted as CV(O), can be represented as : where and CV(O) = [(ns⁰, ic⁰), (ns¹, ic¹), . . . , (ns^N-1, ic^N-1)] 0 ≤ i ≤ N-1 represents all original normal operations at site i ns^i represents all inverse operations for normal operations at site . ic^i = [(ns⁰, is⁰), (ns¹, is¹), . . . , (ns^k-1, is^k-1)] undoing i Also to capture the essential requirements for correct operation execution and transformation, a set of six rules called were introduced. Context-based Conditions (CCs) : Given a original O and a DS, where O ∉ DS, O can be transformed for execution on DS only if C(O) ⊆ DS. CC1 operation document state : Given an original operation O and a document state DS, where O ∉ DS and C(O) ⊆ DS, DS-C(O)² is the set of operations that O must be transformed against before being executed on DS. CC2 : Given any operation O and a state DS, O can be executed on DS only if C(O) = DS. CC3 : Given an original operation Ox and a operation O of any type, where Ox ∉ C(O), Ox can be transformed to the context of O only if C(Ox) ⊆ C(O). CC4 : Given an original operation Ox and a operation O of any type, where Ox ∉ C(O) and C(Ox) ⊆ C(O), C(O) ≠ C(Ox) is the set of operations that Ox must be transformed against before being IT-transformed with O. CC5 : Given two operations Oa and Ob, they can be IT-transformed with each other IT(Oa,Ob) or IT(Ob,Oa), only if C(Oa) = C(Ob). CC6 Due to these conditions and the context vector the COT algorithm is optimized to the extent that it does not even have a need for the transformations. This is made possible because of the context vector that enables a better use of s. ET IT Strengths of the algorithm: Fulfils the convergence property. Fulfils the precedence property. Platform capable of more than text editing. Has been well tested as it has been implemented in several editing programs such as CoMaya, CoWord and more. Problems : Requires more memory than other algorithms because of the nature of context vectors but can be optimized in the same way other algorithms have. 4. Google Wave OT Algorithm Wave OT is basically based on the algorithm given by Jupiter System [dOPT algorithm]. Having a simple and efficient server is important in making wave’s reliable and scalable. With this goal, Google’s Operational Transformation algorithm modifies the basic theory of OT by requiring the client to wait for (In the post, I have explained Client — Server Acknowledgement approach) from the server before sending more operations. When a server acknowledges a client’s operation, it means the server has transformed the client’s operation, applied it to the server’s copy of the wavelet and broadcast the transformed operation to all other connected clients. While the client is waiting for the acknowledgement, it caches operations produced locally and sends them in bulk later. Google acknowledgement [ACKs] second With the addition of acknowledgements, a client can infer the server’s OT path. By having this, the client can send operations to the server that are always on the server’s OT path. This has the important benefit that the server only needs to have , which is the history of operations it has applied. When it receives a client’s operation, it only needs to transform the operation against the operation history, apply the transformed operation, and then broadcast it. This source of truth also forces the client to wait for the server to the operation that the client has just sent which would mean that the client always stays on the server’s OT path. This would help in keeping a single history of operations without actually having to keep a mirror of the state for each client that is connected. That would eventually mean the number of clients that are connected to the server would have only one single copy of the document on the server. One trade off of this change is that a client will see from another client in intervals of approximately one round trip time to the other client. a single state space acknowledge chunks of operations (accumulated batch operations) Google Wave OT solves most of the flaws by its Acknowledge command and by strictly limiting the number of participants in communication to . If the number of clients were increased to three, of the time, conflicts arose. However, there is one flaw that might have slipped through, which is . two 17% intention preservation Conclusion The viable solution would be to incorporate with , since COT would be able to provide a better intention preservation. Also, COT algorithm is not based on when the operation arrives at different places but in what context [CV(O)] the original operation was executed in. Therefore at each site when Oi arrives a comparison will be made with Oi’s context vector and the site’s own document state. Context based OT Google wave OT Also, note that not all Operational Transformation approaches has been taken into considerations. I have merely listed those which I believed are the most significant ones. I would also be researching and writing another post on why Google Wave OT failed in practice by using whatever source code provided by Google implementing a test to prove that Waves OT fails to preserve true intention in practice. Also, I may perform a benchmarking with COT and Google Wave together to know if really COT can be incorporated with Google Wave’s OT. References High Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System Authored by David A. Nichols, Pavel Curtis, Michael Dixon, and John Lamping. Achieving Convergence, Causality Preservation, and Intention Preservation in Real-Time Cooperative Editing Systems Authored by Chengzheng Sun, Xiaohua Jia, Yanchun Zhang, Yun Yang and David Chen. Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements Authored by Chengzheng Sun and Clarence (Skip) Ellis. Compensation in Collaborative Editing Authored by Stephane Weiss, Pascal Urso and Pascal Molli Context-Based Operational Transformation in Distributed Collaborative Editing Systems Authored by David Sun and Chengzheng Sun Operational Transformation for Dependency Conflict Resolution in Real-time Collaborative 3D Design Systems Authored by Agustina, Chengzheng Sun, Dong Xu Proving Correctness of Transformation Functions in Real-Time Groupware Authored by Abdessamad Imine, Pascal Molli, Gerald Oster and Michael Rusinowitch Undo Any Operation at Any Time in Group Editors Authored by Chengzheng Sun A Survey on Operational Transformation Algorithms: Challenges, Issues and Achievements Authored by Santosh Kumawat and Ajay Khunteta A Performance Study of Group Editing Algorithms Authored by D. Li and R. Li Copies Convergence in a Distributed Real-Time Collaborative Environment Authored by Nicolas VIDOT, Michelle CART, Jean FERRIÉ, Maher SULEIMAN Google’s whitepaper on Operational Transformation Concurrency Control in Groupware Systems Authored by C.A. Ellis, S.J. Gibbs Wikipedia on Operational Transformation One of the most informative articles, I have found on wikipedia, suprisingly.

Analysing different Operational Transformation algorithms for collaborative editing

tl;dr: If you go to , your DNS query was served by the Ethereum blockchain! It’s DNS, hosted on Ethereum, and you can use it for any DNS domain. docs.ens.domains Today we’re releasing experimental support for hosting DNS domains on the Ethereum blockchain. This builds on previous work on , the Ethereum Name Service, adding a DNS gateway and support for storing DNS zones inside ENS. ENS For those who want to try it out, a brief howto on hosting your own domain on the blockchain is . This post aims to explain, not how to set it up, but how the system works at a technical level — gluing two different naming systems together. here Background First, a bit of background. DNS, as you may already know, operates on the basis of ‘zones’. A zone represents a division of authority, and a nameserver is responsible for returning authoritative answers to queries in one or more zones that it hosts, while providing references to other nameservers that host zones further down the hierarchy. For instance, when you resolve ‘docs.ens.domains’, your resolver first consults one of the DNS root servers, who respond to the effect that they don’t know the answer, but here’s someone who might — and listing the nameservers for ‘.domains’. Your resolver then asks them the same question, and they respond with a referral to the nameservers for ‘ens.domains’. Finally, your resolver asks those nameservers, and they respond with an authoritative answer: ‘docs.ens.domains CNAME readthedocs.io’. ENS operates in a somewhat different fashion. Unlike DNS, it has a central database — the ENS registry — mapping from domain names to resolvers. In addition, each domain has an owner, who can update the resolver address, and create and delegate subdomains. To look up information on a domain, callers first consult the registry to get the resolver address, then query that resolver to get the answer to their question. Just like DNS, it permits diversity of implementations for resolvers, and delegation of authority within the name hierarchy, but unlike DNS, it has no concept of ‘zones’. How the DNS->ENS gateway works The naive way to store DNS data on the blockchain would be to deploy a single ENS resolver for the existing DNS hierarchy, and expect resolvers pointed to by this registry to support returning zone information for their domains. A gateway could then look up the ENS registry for the domain being queried for, fetch the zone data, and satisfy any queries from that. This works, but has a critical problem: who do you allow to update the registry? You only want the owner of a domain to be able to update their DNS entries, but there’s no obvious way to prove ownership of a DNS domain on the blockchain — especially since you can’t use the usual route for checking name ownership, requiring someone to set a specific DNS entry! Instead, we take a slightly different approach. We allow anyone to deploy their own ENS registry and resolver, and host whatever set of domains they like on it. Then, they include the address of their ENS registry in the DNS nameserver record for their domain. Since everyone has their own registry, we no longer need to be concerned about proving you have the right to update a name — nobody will ever consult your registry unless it’s referenced by the existing DNS infrastructure. For instance, suppose you deployed an ENS registry for your domain, ‘myawesomedomain.com’ at the address 0x1234ABCD, and configured it appropriately. To finish the process, you would go to your registrar, and tell it to set the nameservers for your myawesomedomain.com to ‘1234ABCD.ns1.ens.domains’. Now, when someone wants to resolve ‘www.myawesomedomain.com’, the following steps happen: The user’s resolver does the usual recursive resolution, eventually being told ‘myawesomedomain.com NS 1234ABCD.ns1.ens.domains’. They send a query to that address, asking ‘A www.myawesomedomain.com’. The gateway server at ‘ns1.ens.domains’ receives the query. Before it can answer it, it needs to know if ‘www.myawesomedomain.com’ is actually hosted on ENS, and if so, which resolver is responsible for it — so it does the same query the client did, looking for nameserver entries for ‘www.myawesomedomain.com’. Eventually it gets back the same response the client did, ‘myawesomedomain.com NS 1234ABCD.ns1.ens.domains’. It recognises this, and treats the first part as an Ethereum blockchain address for an ENS registry. Now the gateway server knows where to look, it queries the ENS registry at that address, asking it for the resolver responsible for ‘myawesomedomain.com’. Next, the gateway server asks the resolver for the zonefile for ‘myawesomedomain.com’. It gets back the DNS zonefile data in compact binary form, and unpacks it into memory. Finally, the gateway server uses the unpacked zonefile data to answer the original question it was given, ‘A www.myawesomedomain.com’, and returns the answer to the client. If you’d like to see how all of this is implemented in practice, the — still very much a work in progress — code is . available on GitHub What this means First off, this isn’t automatically more censorship resistant than regular DNS servers. The zone itself becomes very difficult to censor, but for your users to find that, they still have to get referred to it via NS records in the parent zone, so it’s still vulnerable to being taken down or blocked in that manner. Moving the DNS root onto Ethereum would solve this by making every lookup backed by the blockchain, but obviously that’s not something I can hack up for a tech demo. Doing so would also raise issues around DNS zone enumeration: many people don’t want arbitrary strangers to be able to list all their DNS records, and the present solution would make that possible. Likewise, it’s not automatically more secure; you still have to trust that referral from the parent zone, and if you’re using a public gateway (instead of running your own DNS gateway), you have to trust that it’s responding accurately. DNSSEC can be used here just as on regular DNS to secure things better. Again, a system with the root in Ethereum would solve this problem and obviate the need for DNSSEC entirely! What this is a really convenient way to distribute nameserver data to nameservers in a fashion that they know that insofar as they can trust their own DNS resolution, they know they can trust the validity of the data they’re fetching, and that it was written by someone authorized to do so. And it permits this in a fashion that means anyone can utilize the public DNS gateways without having to directly interact with or configure them. It’s also a neat tech demo of ENS. is is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Hosting a DNS domain on the blockchain

Erratic consumer purchasing behavior shook the consumer packaged goods (CPG) —things you buy at the grocery store—industry during the pandemic. As buyers grew more concerned about lockdowns and closures worldwide, they scrambled to fill their homes with the necessities. Post-pandemic, we look back in humor at the bizarre shortages that came about due to consumer panic. Was your home without toilet paper, or did you scramble to find the last few rolls at the grocery store? Frantic consumers upset the rhythms of the CPG industry in 2020, and the fight for toilet paper alone proves that we cannot always predict what consumers will do. Who would’ve thought that toilet paper would be the hottest commodity during a worldwide pandemic centering around an illness that mostly affects the respiratory system? The landscape of the CPG industry transformed at that moment. After months of shortages and supply-chain disruptions, CPG companies must adapt and generate new ways to meet consumer demand. Fortunately, AI-driven technology expedites this process and helps companies meet consumer demand, cater to consumer concerns, and personalize the consumer experience. Anticipate Consumer Demand to the Smallest Detail CPG companies suffered during the pandemic because they were unable to accurately anticipate consumer demand. This is especially problematic for large-scale companies with thousands upon thousands of products. Artificial intelligence bridges the gap for CPG companies by pinpointing the items consumers want, but the specifics about those items. Leading technology solution employs artificial intelligence to make accurate forecasts about consumer demand, down to various sizes and colors of a single product. This prevents loss and maximizes profits by ensuring that inventory isn’t wasted. antuit.ai In their , Deloitte predicted that supply chain resilience will be the key factor to success within the industry. The success of the supply chain directly impacts how quickly the product will be in the hands of the consumer, and thus, whether or not the company will be able to meet demand. 2021 consumer products industry outlook With accurate forecasts, made through the help of AI, companies can determine exactly which materials will be required to create the products consumers desire. This specificity creates a stronger supply chain because companies can prepare for demand ahead of time. AI Makes CPG Sustainable Consumers want to work with brands that have a value system. In particular, , and it is driving their purchasing power. Consumers want to know which brands care about the environment and are making efforts to ensure sustainability. This is especially true in the CPG industry because consumers consider the effects of their everyday purchases. Forecasting through artificial intelligence automatically builds sustainability into the CPG business model by reducing the number of wasted products. Accurate forecasts ensure that supply meets demand, and waste is minimized no matter the product or season. customers are concerned about sustainability Consumers Get Personalized Connection Through AI Companies already collect data about consumers to maximize the efficacy of marketing efforts, but this is falling short. Consumers now expect personalized recommendations, product launches, and experiences that cater to their unique needs and interests. The market is saturated, but connecting with customers can set a company apart. The future of the CPG industry requires that companies invest in personalization for this purpose. Artificial intelligence makes this investment easier. Current artificial intelligence offerings do everything from indexing consumer behaviors on a broad scale to creating personalized profiles automatically as each customer interacts with a brand. This helps companies predict their customers’ future wants and needs—enabling them to handle the supply chain more effectively—and it provides the basis for a targeted marketing strategy rather than overloading customers with content that doesn’t speak to them. The 2020 toilet paper shortage demonstrated the shifts happening in consumer demand, in the CPG industry, and beyond. This isn’t new information, but it’s still critical.  Companies must be ready to meet the demand of consumers. If they are not, they will miss opportunities to capitalize on unique moments in society—like the rush to buy toilet paper at the beginning of the pandemic—because they are unprepared. A detailed understanding of consumer demand will help companies reduce waste, meet consumers’ unique needs, and personalize the purchasing experience so that they can generate a loyal customer base.

What the 2020 Toilet Paper Shortage Can Teach Us About AI

Project management is perhaps the most crucial job in any organization. This is because the success of every project is directly proportional to slowly reaching towards the goals and objectives of the organization that were established well in advance. With the corporate world adopting remote working as their work arrangement, every business is now facing various challenges in terms of management, communication, and collaboration. Consequently, effectively carrying out project management has also turned into a task. To make it easy for managers to handle their remote resources, several software companies have launched digital tools that help to develop a coherent workflow strategy. The software makes it possible for the project managers to automate their work and thus, allow them to put in the minimum effort while keeping the employees motivated. In this article, you can read about these tools and software that help you carry out effective project management with the resources that are working remotely. Tools that are needed for effective project management with remote resources There are a plethora of tools that you can make use of to tackle the challenges that remote working bring with it. Find the top categories of the tools that you should certainly invest in below. Tools that make training easy One of the tools that make initiating training much easier is a learning management system. A learning management system or an LMS is a cloud-based platform that makes developing, deploying, and tracking the training program much more smooth and straightforward for the project managers. There are several vendors now available in the market. Each LMS has its own set of features and price models, which are also the two major deciding factors. In order to ensure that your LMS is cost-effective, it is often suggested to identify the features that you require and explore the LMS that aligns with those features. Take iSpring Learn for instance. include certification management, gamification tools such as badges, mobile support, graphic reports, and more. Moreover, this LMS has a subscription-based pricing model. Now, you would want to invest in this LMS is the features and pricing model fit well with your goals and budget. iSpring Learn features Tools that help to communicate better One of the major challenges that a project manager faces is that of ensuring seamless and smooth communication. Employee engagement is of utmost importance for every organization to succeed, be it external or internal. This is where the communication tools by software companies play a key role, especially during the times of remote working. There are several communication tools that you can choose, depending upon the requirement, preferences, and objectives that you have established. However, your communication tool should allow you to not only exchange conversations with every employee individually but also enable you to indulge in text-based group discussions, share files of various formats, and help to resolve any roadblocks in terms of communication. The most commonly used communication tool today is Slack. This tool helps you cross hurdles in regards to communication, allows you to streamline your workflow, and thus, helps to improve the productivity of your remote resources. Tools that allow virtual communication One thing that lacks when you are working remotely is physical or face-to-face interaction. Face-to-face interactions are often required to exchange information better and also to interpret the body language or facial expressions of an individual. It is through face-to-face interactions that your employees feel motivated and a part of your organization. To solve this problem while working remotely, there are many video conferencing tools that are now available in the market. These tools have additional features and characteristics that can make communication more interesting. Google Meet, for instance, is a commonly used video conferencing tool that helps you indulge in face-to-face interactions and also allows you to present your screens while presenting something. Conclusion Project management gets difficult during the times of remote working. However, you can easily overcome this challenge with the help of the tools that are mentioned above.

3 Types of Tools Needed For Effective Project Management, Remotely

In the we looked at how operating systems, phones, tablets, smartwatches and smartglasses changed through the last decade. The 2010s changed how we interact with technology, but more importantly, how we think about the impact it has in our lives. first part of the series “Time travel through 2010s technology” So what happened in the last ten years? How did we get here? Transportation Directions while driving in 2010 usually meant having a dashboard-mounted GPS unit like a TomTom or a Garmin. Updating their maps was cumbersome, and using smartphones for car navigation was a new trend still in its infant days, in part due to the tiny screens (3.5 inches was a regular screen size back then). Embedded GPS used to be an expensive car add-on, but nowadays, most people simply have a phone holder on their air vent and use Google Maps or some other app on their smartphone to get up-to-date directions. Moreover, with the advent of systems like Apple CarPlay (2014) or Android Auto (2015), proprietary car systems have started getting obsolete real fast. The car industry started moving closer to the tech industry as the decade advanced, and today, most cars’ selling points involve some sort of tech that makes driving a safer or more comfortable experience. Comparing a car dashboard from 2010 with a Tesla Model 3 dashboard demonstrates the direction we are headed towards. Electric cars are making a comeback and they are slowly getting closer to the affordable price points that hybrids had 10 years ago. In 2019, most of the car manufacturers in the U.S. finally have plans to produce electric cars in mass quantities. Perhaps the biggest change in transportation comes from the push on automated driving systems. Since 2015, Audi, Waymo, Uber, Tesla and others have been racing to produce a self-driving car that can be thrown onto our roads and provide a safer trip than those cars driven by humans. Policy-makers are struggling to regulate around a technology that is evolving faster than our laws or infrastructure. We are quickly reaching the point where we have to wonder if the best solution is to separate autonomous vehicles from human-driven ones. In any case, semi-automated vehicles —where the car can keep us centered in our lane, or switch lanes without much human intervention— have become a stop-gap until we get our act together with fully autonomous cars. Social media Social media companies started the decade with a strong position: 2010 was still a time when many of us were sharing a lot of personal details on social media sites like Facebook, and we were communicating with a mental freedom that today would be considered unnecessary by many. The 2010s were a decade where many learned to trust the cloud as a safer place than our own computers, but as companies tried to speed up development of new features, mistakes were made and missed. Vulnerabilities went unnoticed and it became a matter of time until bad actors would exploit them for profit. There have been more cases of data breaches than I can enumerate in this post, but what’s clear is that the past decade has helped many people interiorize that no system is totally secure. If a vulnerability exists, it will be found and eventually exploited unless fixed. Simply put, society was not self-aware of their own privacy risks in 2010. Notably, in 2013 this began to change at a faster pace, as Facebook started suffering multiple that pushed customers to realize how their personal information was at risk. These exploits allowed third-party companies, like Cambridge Analytica during the U.S. presidential elections in 2016, to have access to personal data that was supposed to be private. data breaches and platform vulnerability exploits There were several consequences after all of these issues. First, the EU’s General Data Protection Regulation (GDPR) was made in 2016 and implemented in 2018 to protect the privacy of EU citizens, starting a wave of data policy changes in many international tech companies. Second, companies started selling privacy as a feature, and those whose business model didn’t depend on customers data —like Apple— benefited from using a marketing narrative that distanced themselves from the privacy storm. Third and last, users were forced to take a step back and reevaluate how their privacy was impacted by social media, and how much data they wanted to share in the first place. Ironically, this had as a side effect the birth of a new business opportunity: ephemeral social media services, where a user’s post is automatically deleted after a certain period of time. Companies like Snapchat were born in 2011 out of this premise, and Facebook was quick to adapt products like Instagram (acquired by the Palo Alto giant in 2012) to cater for this new trend. Another challenge that social media companies like Facebook or Twitter had during the last decade is still very present today: hate speech and misinformation are easy to spread within social circles of like-minded people, and personalization tools make it seamless to see only the content we already love. This led to polarized bubbles that divided our society, especially during election cycles. Many social media services like Google Buzz, Google+, Vine and iTunes Ping didn’t live to see the end of the decade, and were followed by a new generation of social apps centered around visual content, like Instagram, Snapchat or TikTok. Will they survive the next ten years? AI and automation Artificial intelligence (AI) is a discipline practically as old as computers themselves. Every single big tech company recognize the potential and value that “intelligent machines” can have in many areas of our lives and started developing machine learning solutions that can be successfully specialized in scoped environments. Through the 2010s, we have seen a proliferation of these specialized AIs, starting with IBM’s Watson, which in 2011 defeated without effort the greatest champions in the show’s history. Google’s AlphaGo is another valuable example of how good domain-specific AI has gotten in the last decade. Jeopardy! However, the biggest impact in our daily routines doesn’t come from powerful computers trained to do one thing very well. It comes from the integration of AI on products that we can use anytime, every day. Amazon, Google, Apple and Microsoft, all have invested copious amounts of money in developing the best natural language processing systems to be embedded in their respective virtual assistant. With total certainty, anyone reading this article has an AI within hand’s reach. Alexa, Google Assistant, Siri and Cortana, all have been developed with their own personality. These conversational AIs are now accessible through thousands of different devices and form factors. One of the most significant changes in human interaction with technology this decade is precisely that we can now talk to machines in a somewhat natural manner. We can turn on and off lights, appliances and TVs, switch channels, ask basic knowledge questions, get directions, set reminders, start video-chats, order food, buy stuff… and there are new use cases being added every day. Siri was first introduced as an app for iOS in 2010, and got acquired by Apple just two months later. Alexa was developed by Amazon and released in 2014, almost at the same time as Microsoft’s Cortana. Google Assistant was released in 2016. In the second half of the 2010s, these virtual assistants have been improved with features out of a science fiction movie, like the ability to whisper, matching our own voice tone, or the ability to emulate a human and make a dinner reservation without letting the interlocutor know that they are speaking with a machine. Commercial AI has become smart enough to understand follow up questions, or recognize who’s speaking. By integrating with home automation sensors, a virtual assistant can now guard the house when we are not home and alert us of noises, or simulate that we are home by randomly turning lights on at night. In 2010, automating a home was costly, and limited to routines often out of reach to the average consumer due to the lack of user-friendly programming interfaces. A decade later, home automation has become an inexpensive option available not only to the rich, and anyone can retrofit their house to be “smart” without much effort or deep technical expertise. Unfortunately, AI also evolved during the 2010s enough to get weaponized. AI helps corporations process vast amounts of data that can be used to manipulate people. It enhances robotics and drones, creating lethal autonomous weapons. It’s used to power automatic face recognition systems that limit people’s freedom of movement and privacy. Nonprofit organizations like OpenAI are championing , but as we continue developing this powerful technology, having proper government regulation becomes more necessary. responsible AI development As we enter 2020, a new and important decade is ahead of us. A critical decade for our planet’s worsening health, critical for healing a polarized society and for reducing the inequalities that still exist across the world. The challenges that we are facing will be difficult to solve in an environment full of sociopolitical complexities, but I’m confident that technology can and will be a progress enabler. Technology helped make the world a better place during the 2010s, but also created imbalances that need to be corrected if we want a sustainable future. Let’s work together on making sure the next decade is even better than the last one, for everyone, everywhere. Did you like this article? Subscribe to get new posts by email. Photos by Josh Newton , Kristian Stokholm and Annie Spratt on Unsplash

Stories, News & Mentions about NS1

Ns1’s Stories on HackerNoon