So, this hour we're going to talk about APIs, APIs. Who here is an API producer? Who is created and released an API? Okay, maybe about a quarter to a third. All right, who here is a web developer? Who has released a website? Okay, that's about at least half, half to two-thirds. You too are API producers. You're writing code that's designed to be called by other codes, like a web browser. So, you also have produced an API. Now, who here has written the class? A Ruby class, Java class, C++ class. Most hands should be up, okay. All right, you also are API producers. You are writing code that is designed to be called by other code. Now, in this hour, we're going to focus on network APIs, not class APIs. So, some of this will apply to classes and other parts of it won't. Some of the underlying principles will be the same though. Okay, last question. Who here speaks a language? English, Japanese, Spanish, Hindi? Everyone's hands should be up. All right, you are not necessarily API producers, but you're doing many of the same things. You're communicating, you're interacting with something else. Some other person, you're communicating. So, this is something that we all do. It can be useful to think of APIs in terms of communication. So, we'll come back to that. But in this hour, we're going to talk about APIs. We're going to talk about APIs. In particular, we're going to focus on client libraries, API client libraries. Now, what is a client library? It's a Ruby gem, a Ruby library that provides a nice Ruby interface for calling an API, a network API. So, suppose you've built an API, maybe it uses HTTP, JSON. Users can call your API using a standard HTTP client, for example. So, here's a simple example that might use net HTTP as part of the Ruby standard library to call an API. So, you construct an HTTP request, maybe marshal some JSON data, and parse a JSON response. There was a lot of text up there. But what if you could make that same API call by just invoking a method? Something like this. This is clearly a lot shorter, a lot easier than constructing that HTTP request. We could say this is a better kind of user experience for your users, or since your users are developers, this is a better, happier developer experience. Of course, this means that you have to write that class. You have to write that example client class that will provide those methods. You have to build it into a library, and then you have to maintain it. You have to keep it up to date. You have to document it and all that baggage. So, how do you do all that? What are some techniques that you can use that go into a good client library? And is that engineering effort worth it? It's all the effort needed to maintain that worth it. Those are some of the questions that we're going to go over in this session. We'll think about why an API client library might be useful. We'll talk about how it can provide better, more happy developer experience for your users. We'll see some of the common features of client libraries, some of the techniques and the practices that go into writing them. Then we'll talk about tools that might help you generate client libraries for your APIs. So before we get started, just a bit about your speaker. My name is Daniel Azuma. I've been part of the Ruby community for a little while. I've been developing in Ruby for about 13 years. I did Java and C++ and other things before that. I've kind of done a variety of things. Currently, I work at this place where I serve as the Ruby engineering lead for Google Cloud. My job here is to make the cloud better for Ruby developers, for people like you. And one of the major areas that my team works on at Google is looking after the Ruby client libraries for Google's APIs. Google, of course, is a large company with lots of products, lots of APIs. We have several hundred public APIs right now. That doesn't include all of our internal services, of course. And so we provide client libraries for all of those APIs. And that means several hundred services. And if you multiply that by the number of languages we support, programming languages, that's a lot of code to maintain. So when you get to that point, you start to wonder, is it worth it? Is all that effort worth it? Is all that engineering effort to maintain a client library worth it? When you could just have your users just construct HTTP requests, is it worth it? Most of you probably don't have to deal with the kind of scale, of course, that we have at Google, but it's still a good question. And it's a question that I once faced early in my career, long before I joined Google. So imagine me early in my career, maybe not that early. It was a number of years ago, but there, that's better. I was at a startup. And we were a Ruby shop, and we were writing a back-end API for a mobile app. Now my team, we were all back-end developers. We were Ruby devs. And we didn't know very much about mobile languages and mobile frameworks at that time. It was pretty early. So we hired an external engineering team, it was actually an offshore team, to do our mobile development for us. So we, my back-end team, we deployed our API to staging and we documented it very carefully. We documented it, because we didn't know what kind of tools and what kind of libraries that the mobile engineering team had at their disposal. We didn't want to take the time to learn those mobile languages and mobile frameworks ourselves. So we documented this, we created this spec, and we sent it to our mobile team. And about a week passed, and we started getting emails from them, saying, hey, you know, we don't understand this. We don't understand this part, or we can't get this or that to work. First it was the auth. Then it was the security, the request signing. Then it was the session handling. Then it was the instrumentation. Then it was back to the auth and how it interacted with the session handling. Back and forth, around and around, I had thought that we had documented this pretty well. But apparently I was wrong. Soon we started having late night meetings with them. This mobile team was offshore. So they were in an opposite time zone. I had to stay up in the office until about 10 or 11 every night. And we had these late night meetings with them. Then late night remote pairing sessions with them. I ended up learning a lot about mobile languages and mobile frameworks. But this was not a great developer experience. Not for me, not for our mobile team. All in all, we lost three, maybe four weeks to this. Just getting the two sides of the API to talk to each other before the team even got started on the mobile interface itself. Some of you are on startups today. Three or four weeks, that can be an eternity when you're bootstrapping a startup. So later on, after we finally shipped, we got together and we talked about this. What should we have done? Should we have written the mobile API code ourselves? Would that have helped? I'm actually not sure. Maybe it's a tough question. I don't know. What I do know, though, is that this experience opened my eyes to the fact that APIs are hard. APIs are really hard. They're hard in many ways. They're hard in resource design. If you have a restful API, mapping your problem domain into resources is hard. Naming is hard. Versioning is hard. Future-proofing your API is hard. But also using an API, calling an API, can also be hard. For example, auth. Enough said. Who here has implemented an auth flow? Who here has gotten it right the first time? There we go. Here's another one. Retry. When can you retry safely? How many times do you retry? How long do you wait between retries? All that exponential backoff. What if you get quota errors? Do you still retry? Do you retry differently? It's complicated. Here's another one. Caching. Oh my gosh, I don't even want to talk about caching. As an API user, there are lots of issues that you have to deal with, that you have to keep track of beyond just the request and the response. You have error handling. You have instrumentation. You have long-running operations, long list of things. In general, real-world APIs are much more than just HTTP requests. This morning, Matz shared with us that he sees programming languages as a form of expression of ideas. You remember that? I think it's a very apt description. And I think it very much applies to APIs as well. They are a form of expression of ideas. So for example, consider what we're doing here in this room. I'm standing up here and we're sharing ideas. I'm giving you content. I'm giving you words. But sharing ideas, communication, is much more than just words. There's a lot of side channel information going on here, being passed back and forth. So for example, I might emphasize certain things because I want you to understand that they're important. I might emphasize certain things. I might gloss over something else because, yeah, whatever. Emphasis, tone of voice, facial expressions, a lot of side channel information. It goes both ways. I'm standing up here talking, but I'm also observing. Who's listening and who's sitting there on your laptops writing email? What kind of how are you all reacting to things? There's also context, the order in which things are presented and discussed. That matters. Setting matters, the fact that we're at a Ruby conference in this beautiful space. It shapes our conversation. Identity matters, the fact that I'm a Ruby developer and a Google engineer. You hear me differently than if I were a US senator or if I were a barista or if I were Mott's or if I were Aaron Patterson, then you would definitely hear me differently. All of these things, not just the content, but also the context and the side channel is all part of this sharing of ideas. And of course, you know this already. We all do this. We all communicate. We all understand, to some extent, what these things mean, what all the side channel means, what the context means. There's a protocol to human communication. There's a protocol to the sharing of ideas. And you are familiar with that protocol. And that's what I would say is the role of the client library. It's to know the protocol. It's to know the protocol. Not just the HTTP or JSON protocol, but also the auth, also the retry, the sessions, the caching, all of those side concerns that are not handled by your HTTP library. Now you provide a client library to handle all that protocol so that your users don't have to deal with it. All right? So that's all nice, that's all hand wavy, that's great. What does this mean? What does this mean really in practice? So let's take a look at a really simple example. This is a simple example of an interaction with a client library. This happens to be for Google's Translate API, but it's pretty typical of many client libraries. You notice that once we create an object, the object represents the service. It's sometimes called a stub object because it represents the service, but it doesn't implement the service. So we have an object. Typically the stub object encapsulates some of the basic concerns of communicating with that service. A lot of that side channel information, such as identity, auth, timeouts, and so forth, is encapsulated here in this object. And then actual API calls can be made by calling methods, okay? Very straightforward. And typically, of course, results come back as objects, and then you can pull out information from them, okay? Now notice what we don't see here. Notice what we don't see. We don't see URLs. We don't see JSON or HTTP. This might be an HTTP JSON API, but that's just the protocol. It's not part of the functionality of the API, so it's not what your users care about. And we also try to hide other difficult issues, like retry, like caching. This is all very important, hiding certain things that the users don't care about for creating a happy developer experience. Developer experience, we're gonna talk a lot about developer experience because it really is at the core of what drives a client library. And again, I'm really grateful to Matz this morning for reminding us that developer experience is really at the heart of our values as Rubyist. Things like happiness, niceness, productivity, community, the experience of being a developer, having that be happy, having that be enjoyable. So let's talk about a few pro tips. Let's talk about what sort of things go into an effective client library and can give your users a happy developer experience. First, as much as possible, use the Ruby abstractions. Use the abstractions that are provided by Ruby, Ruby idioms. So make the usage of your library familiar to Ruby developers. This may seem obvious, but let's talk about what that means. It means on the one hand, using standard Ruby classes for data. For example, if you need to express a timestamp, Ruby has a time class for that. It means integrating with the standard Ruby libraries for things that's appropriate for. So if you're writing a client, for example, for a logging API, Ruby has a logger class. That's how Rubyists expect to interact with a logging system. So use that. Here's a good example from ActiveRecord. Who here uses ActiveRecord? You have Rails developers, lots of Rails developers in the house. That's great, you're welcome here too. This is a Rails conference as much as a Ruby conference in reality. Now this is how to iterate over all the records in your database. ActiveRecord provides a method findEach that returns a Ruby enumerator. You can also pass a block to it. But enumerator is the standard Ruby abstraction for kind of a stream of data, a stream of objects. Under the hood here, ActiveRecord is actually doing something that you might not expect. It's actually making multiple database calls. Getting a batch of records at a time because you might have a large database table and you don't wanna load that entire thing into memory at once. But since it gives you an enumerator, a standard Ruby abstraction, you don't have to worry about all that. You just make one call, you get an enumerator and now you can do all sorts of things. You can transform the data, you can iterate over it, you can make it lazy, all these things as an enumerator. You have all that power of Ruby available to you. So use Ruby abstractions to help your users and give a happy developer experience. Second thing, errors will happen in your API. As much as possible, handle errors in your client library. Handle errors for your users as much as possible. This is because error handling is really annoying. Error handling is really annoying. A lot of different things can go wrong and each problem demands a different response. You might have server problems, you might have network glitches, your all off tokens might expire, you might have quota errors. And who has time to figure out how to handle every single one of those cases properly? So as much as possible, your client library should handle its own errors. That might mean handling retry for your users. Handling quota so your users don't have to do it. Anything that you actually have to report back to the user then, translate it into an exception, for example. So your users don't have to look up error codes and then have a big case statement. Again, very important for a happy developer experience. All right, let's talk about security. Security, this is another meticulous, difficult, detailed concern that's really hard to get right. So help your users out in the client library. Do things like check inputs. Obviously that means check types, check ranges, but also do escaping for your users. Sanitize all the inputs. ActiveRecord does this for you again. Don't make your users do this themselves. Help your users prevent those SQL injection attacks. Very, very important. Also, if there's a security or some kind of encryption protocol that has to be implemented, build that into the client library. Just last week, I read a blog article from someone who was really struggling to implement the request signing that was required for this API that they were calling.  Don't make your users go through that. So give them a client that handles that. Now, one objection that I sometimes hear regarding client libraries is, oh, it's an extra layer of abstraction, so it's just gonna hurt performance, right? There's this fear that there's gonna be a performance impact. Let me tell you a secret. This is nonsense. Generally speaking, in the network API, the network latency, database latency in the backend, something else is going to dominate your performance. So a client library generally is not gonna make it materially worse. In fact, oftentimes, the reverse is true. A client library, a good client library can often improve performance. How does it do this? Because it gives you the chance to help your users do the right thing when it comes to performance. Your client library can help with performance optimizations that only you know about your API. It can help with best practices, such as proper caching, batching calls, and so forth, so your users don't have to do it themselves. So let's think about, again, a remote logging API. Typically, in a logging API, users write a log entry, it gets transmitted to a backend, indexed, stored, and so forth. And if your user has had to send an API call for each log entry, and if that's an HTTP request, you're waiting for an HTTP request in response. Don't do that. That takes time, and that's not cool. Logging's supposed to be fast. Even if you do that kind of asynchronously, you send a request and don't wait for the response, and you have other problems, right? You have to deal with asynchronous behavior. You have to deal with what happens if now you can't retry. So instead, a good logging API will typically provide a batch send call, right? So it's a call that will send a whole bunch of log entries at once. And then in your client library, whenever the user writes a log entry, just queue it up in the client library. So you keep a queue of these log entries. Then after the queue gets to a certain size or a certain amount of time is elapsed, then use that send batch call to transmit all those log entries back to the backend. Better yet, do so asynchronously. Use a background thread, use a background agent process. Do something like this. A system like this is critical for acceptable performance in certain APIs like a remote logging API. But again, something that can be really hard to do for your users, especially if you're dealing with asynchronous behavior. So don't make your users do it. Provide it in the client library. Again, very, very important for this happy developer experience. Finally, client libraries should provide instrumentation. Instrumentation. This means gathering information about usage. Gathering information includes things like logging calls, logging events, log all the errors that you encounter when calling an API. And that includes the ones that you retried and succeeded. Don't throw any errors away. Those errors are important. Users need to know about them. All very valuable information for both for your users as well as for yourself as an API provider. Logs, traces, latency tracing, very useful information, statistics. Your client library can, to do this sort of thing, it can integrate with a system like OpenCensus to collect statistics, to collect trace information. If you expect your users to be Rails apps, you can use active support notifications, lots of different libraries that you can use to help you with this sort of thing. However you do it, it's very important to instrument your API usage and to do that in the client library so that you and your users can have visibility into what's going on. So we have a list of very useful, very important services that a client library can provide. Sounds great, very nice. Very nice for our users, but it does seem like a lot of work, right? Especially if you have Google's problem. So here's what we do at Google and what many organizations, both large and small do. And it's a technique that you can use as well. Use what's called an interface description language, or IDL, interface description language. This is a machine-readable specification of your API. It's a description of your API that can be parsed and understood by a program. An IDL description describes things like what calls are available in the API, what parameters need to be passed and what return values are generated, any data types that are used by the API, other properties of API calls, such as whether it's idempotent, what kind of authentication is needed, and so forth, and also oftentimes documentation for each API call is represented in an IDL. Now, when I talk about IDLs, I can sometimes tell who out there are the old timers who have been doing enterprise development for some time because they start cringing and start showing some signs of PTSD. They might be thinking about something like this that brings up memories of all sorts of terrible things. IDLs have been around for quite a while and some of them are not pretty. Enormous complicated XML files that are just no fun to deal with at all. But I'm here to tell you that it's not that bad anymore. So here's an example of what a modern IDL might look like. This one is in an open format. It's called OpenAPI. Some of you may know it as Swagger, which is an earlier name for it. The open version now is called OpenAPI. You can see some endpoints information, basic endpoints and metadata, as well as a description of one call, a user's call along with a description of what its responses look like. You can see it's YAML, so it's very readable, still very expressible, expressive, flexible, but not too scary. Now there are other IDLs, Apache Thrift is another common one, came out of Facebook. Google uses protocol buffers, GRPC. One thing that all these formats have in common, of course, is that they are machine readable. That means once you have a specification, you can do all sorts of cool things like generating client libraries. So what if you could have a program read the specification and automatically spit out client libraries for you? That would be awesome. So in Ruby, we have a couple of general approaches that we can do to do something like this, because Ruby is a very dynamic, very powerful language, so one of those is metaprogramming. Ruby has a number of very powerful metaprogramming features. You can dynamically create classes, create methods at runtime. So you could build a client library that looks kind of like this, reads an API description from an IDL file, and then metaprograms your library. So you can imagine having a single Ruby gem that can handle pretty much any API just by reading an IDL and generating classes for you. This is actually how some of the early versions of Google's API client libraries worked. They called a Google service called the Discovery Service that served these IDL files and then used that with metaprogramming to build clients, client classes dynamically. So we had a small library that did this, that pretty much we covered all of Google's APIs with a small library. It was really cool. It was also really annoying for our users because metaprogramming makes for very obscure code. If you wanted to understand how the client worked internally or if you got an exception or something and you had to dig through a stack trace, you ended up wading through these layers and layers of metaprogramming. It also meant that we didn't have very good or sometimes any documentation for the library because our documentation tools like our doc, like Yard, they have a hard time figuring out what to do with metaprogrammed code. So again, developer experience, not so great, not so great. So most modern client libraries use a different approach. Code generation, code generation. And after a short while, we switched Google's client libraries to use this approach. So what does that look like? The idea here is to take the generator that reads the IDL and generates classes and pull that out of the library. So instead of doing metaprogramming inside the library, we pulled that out and we just had its write Ruby files, write.rb files. We had the generator generate the library itself as static Ruby classes. And because it generates static Ruby classes, they can be used also to generate other things like associated documentation. You generate the comments that go with those classes that get turned into our doc or your doc. You can do that straight from the descriptions or the comments that you have in the IDL file. So now you not only have automatic code, automatic client libraries, but also automatic documentation. That's pretty cool. And in fact, you can get automatic of all sorts of things. Skeleton code for the server side, even tests. I would love to have a computer write my tests for me. Be awesome. Google does all of this kind of internally for our client libraries. If you go to almost any organization that generates lots of APIs, they're doing similar things. They're generating clients, generating documentation. Code generation in general is a really fun topic. If you wanna learn more about it, my colleague Alex is up here. We'll be speaking on it tomorrow afternoon. Raise your hand, Alex. I highly recommend his talk. But you don't have to be Google to get started. Client libraries are important no matter how big you are. And you can use these kind of generation tools, IDLs, even if you're just getting started. They're still useful. So here's how you can get started. First, choose a specification format. Again, there are small handful of choices out there. Being a Googler, I might plug Google's formats, which are protobuf and gRPC. And if you're looking for a really high performance kind of ultra scalable system, that might be the way to go. But honestly, in order to get started, especially if you already have a REST API that you want to work with, then consider OpenAPI. It's open source, has wide adoption, and very good tooling. So once you've chosen the standard, then write a description of your API. So write it in that IDL format. This will be the input for your code generation. I've also found that writing this is really useful for kind of honing the design of your API, kind of cleaning that up. Because you can see all of it in one place. And it's really not that bad. If you use OpenAPI, there are also online tools that you can use to help you write it. Third, once you've got a description, then you can start playing with a client library generator. The OpenAPI generator supports lots of languages, including Ruby, so you can generate just kind of a starting point library. Then once you get a basic client going, you might have special requirements for your API. And so it's really easy to customize those generators just by editing templates. So just a few steps, and you'll be well on your way to creating your own client libraries for your APIs and generating them automatically. So just to recap here is what we've talked about. We talked about why you should consider providing an API client library for your API. We talked about what a client library should do, what API concerns it should handle, things like retry, things like security, so your users don't have to deal with them. We talked about how to generate client libraries. Even if you're supporting hundreds and hundreds of APIs across lots of languages, you can use cogeneration to maintain clients and maintain those documentation, even using a pretty small team. We have a pretty small team at Google that does this. However you go about doing this, a client library can be very, very important, a key part of creating that happy developer experience. And your API is worth a happy developer experience. And we as a community, we're about a happy developer experience. So yes, you should provide a client library for your API. So thank you for coming. I've put together a set of getting started resources. It will be at this URL, so if you need to photo your phone, that's the URL to capture. It's not up yet. I will have it up by the end of the day. But the slides, when they're posted will be there. The video, when it's posted will be there along with a bunch of links, articles and stuff that I've collected. So feel free to look at that. I think we have a few minutes. Do we have a few minutes for questions? See ya. Okay, we have a few minutes back there, yes. Yeah, so the question is, how do you handle versioning of APIs? When you make breaking changes and your API contract changes, what do you do in your client APIs? It's a hard problem. At Google we actually do two different things. Number one, we do express the version explicitly on our API clients, so you can choose when you create that stub object, you can choose version one or version two of the stub object. You know, it's just a parameter in the constructor. You can also do things, and we also do this in a few of our client libraries, create like a veneer over the generated code that tries to smooth out some of the differences in the API specification. So some higher level interface that for commonly used operations that would call down to those lower level generated code. So a couple of techniques that you could use, but yes, it is a difficult situation. GraphQL, I think people are using that as well for some of those issues. Yeah, anything else? Okay, I don't see any other hands, so thank you for coming. Have a great day.


The Air Force Civil Engineer Support Agency has developed the following video program to support the Air Force qualification training program. This video covers step-by-step procedures for a specific task identified in the specialty training standard of the Career Field Education and Training Plan. This video does not take the place of on-the-job training. It is not intended to replace the applicable technical reference. However, this program is intended to enhance the on-the-job training process, standardize the training procedures, provide just-in-time training, and provide the minimum knowledge on a task or piece of equipment when a unit does not have the equipment. We hope you'll find this video program a valuable training tool. This Civil Engineer Air Force qualification training program videotape contains front-end loader operations, level, stockpile, spread, and backfill. Driving to work can be a rewarding experience for those people who take an active part in the base's appearance. Just take a look around and you'll see well-maintained buildings and neatly trimmed lawns and landscaping. Most bases have flag displays and vintage aircraft depicting their history. Your civil engineer organization is responsible for these facilities and grounds. How well they fulfill these requirements is a direct reflection on the proficiency of the people in that organization. The pavements and construction equipment operators have a significant role in the maintenance and appearance of the base's real property. They'll use a wheeled, mounted front-end loader to accomplish this mission. This versatile piece of equipment is used almost daily for a variety of jobs. Today's program will discuss four typical tasks that you'll be expected to perform with the wheeled, mounted front-end loader. These tasks are leveling an area, stockpiling material, spreading material, and backfilling a ditch or trench. There are two different leveling techniques that can be accomplished with a wheel-mounted front-end loader. These techniques are commonly referred to as the dozer position and back-dragging. Either technique is suitable for knocking down small piles of material or filling in and leveling irregular surfaces. The dozer position can only be accomplished with a front-end loader equipped with a multi-segment bucket. If your loader is equipped with a standard bucket, you'll have to use the dragging technique. Let's discuss the dozer position technique first. Open the bucket segments and tilt the bucket back until the bucket position indicator aligns with the dozer position mark. The front segment should be opened a couple of feet above the ground. The rear segment should be almost straight with the cutting edge angled approximately 45 degrees. With the bucket set in this position, the cutting edge will just skim the surface and pile the material up against the back of the bucket. Set the cutting edge on or slightly above the ground. In this operation, you do not want to dig with the blade, so you'll have to pay close attention as you move the front-end loader forward. Slowly ease the front-end loader into the material to be leveled and watch the bucket. Your vision will be obscured, so you'll really have to feel what's happening to the loader and listen to the sound of the engine. As you move forward over the low spot, raise the blade in small increments for better distribution of material. Continue moving across the low spot. It's better to go slow and make an even distribution than trying to level too much too fast. When you're across the low spot, stop the front-end loader. Raise the bucket and return for additional material. Make as many passes as necessary to level the material and fill the low spots. You may have to change your front-end loader travel directions in order to fill all the low areas and level all the material. The other leveling technique is back-dragging. This technique can be performed with either type of bucket. Buckets with the front teeth removed generally produce smoother back-dragging operations than buckets with teeth. To set the bucket up for back-dragging operation, verify the bucket is in the bucket position on the bucket indicator gauge. Lower the bucket to the ground and tilt it backwards just slightly. This backwards tilting will raise the bucket teeth and keep them from scarring the ground and leaving small ruts. This technique is accomplished only in the reverse travel direction. Place the bucket boom control in the float position. This will allow the weight of the bucket to catch the high spots of material and float over the low spots. Slowly start backing the loader. The bucket will travel across the ground catching the high spots and depositing the material in the low areas. When you reach the end of the pass, raise the bucket slowly to feather out the remaining material. Return to the starting point for another pass. Don't forget to set the bucket up correctly and back slowly as you level the material. A number of passes may be needed to level the area. The direction of travel may also need to be changed in order to get the area as smooth as possible. These wheel-mounted front-end loader leveling techniques are generally considered a rough level. For small areas, the front-end loader works extremely well. However, for large areas, you'll probably need to bring in the grater to put the finishing touch on the leveling operation. Anyway you look at it, it sure beats the alternative. There are two pieces of construction equipment used to establish stockpiles, the crawler tractor or dozer, and the front-end loader. Most stockpiles established on a job site are created with the front-end loader because it's usually easier and faster than a crawler tractor. Plus, the piles of material can be stacked higher without the equipment walking on and compacting the material. Stockpiling is best accomplished on a flat hard surface free of larger rocks and debris. You'll also want to avoid areas that are prone to flood and have poor drainage. Place the front-end loader bucket in the bucket position. Lower the bucket until it is flat and level on the ground. If you're not familiar with this particular front-end loader, there are a couple of items to check to ensure the bucket is flat and level on the ground. First, make sure the bucket position indicator gauge is pointing to the bucket position. Over time, these indicators can be abused and therefore not be real accurate. Dismount the front-end loader and physically check to make sure the bucket is resting flat and level on the ground. You'd be surprised how many times it isn't. If everything is okay, remount the front-end loader for the next step. Move the front-end loader forward toward the material to be stockpiled and continue to skim the ground as the material flows into the bucket. Push the material until you reach the designated stockpiling spot. This spot might be indicated by a grade stake or an existing stockpile of material. Stop the loader, raise the bucket. This might be a good time to engage the clutch cutout feature and dump the material. A number of passes will be required to collect the material for the stockpile. As you make another pass, keep the engine speed only high enough to move the loader forward without spinning the tires. The bucket may have accidentally started to dig into the ground instead of just skimming over it. If this is the case, roll the front edge of the bucket back just a little and continue moving forward. Likewise, the bucket may also be curled back a little too much and it just skims over the ground. When this happens, the bucket will tend to create a slope or ramp as it approaches the stockpile. To eliminate these problems, double check the bucket position indicator gauge pointer. You may have to set the pointer on either side of the mark for the bucket to be perfectly flat and level. Continue making passes around the stockpile area until the area is smooth and level. The material gathered should be piled as high and uniform as possible. On some projects, dump trucks will deliver material to be stockpiled. Have them dump as close to the stockpile as possible. As the stockpiler, you should plan on assisting the dump trucks. Indicate where you want the material dumped. You may also need to spot the trucks when backing is required. Clear directions by the front end loader operator and accurate placement by the dump truck driver will significantly reduce the stockpiling effort. Stockpile this material as high as possible to make room for additional loads and to reduce the area needed to store the material. Clean up all the little mounds of material around the stockpile. The area should be smooth and level. This will help the trucks entering and leaving the area. Plus, it's a lot easier on the front end loader operator. Try to keep the stockpile shape uniform to prevent material shifting during inclement weather. Be aware that loosely compacted stockpiled material may give way and cause the loader to turn over. The last point we want to make on stockpiling is to be aware of the different types of material and sizes of aggregate that you're handling. Material that has a mixture of fines and large particles will tend to segregate if handled too much. Build the stockpile in layers to avoid segregation of material. Stockpiling material is a simple way of gathering material in one central location. When a dump truck brings fill material to the construction project, they can easily spread the material and save a lot of work. This is great if you have a lot of material to be spread. But what do you do if you only need a small amount of fill spread at various locations throughout the site? The front end loader can easily make quick work of this task. There are several different spreading techniques available depending on the type of front end loader bucket. First, let's discuss the spreading technique using a front end loader equipped with the multi-segment bucket. Load the bucket with material to be spread. Proceed to the low area with the bucket positioned close to the ground. Watch your speed as you don't want the loader bouncing and spilling material. Spreading a small amount of material within a specified area is a real challenge. It's hard for the front end loader operator to accurately judge material placement. While grade stakes establish the boundaries, a spotter can really assist you in placing the right amount of material where it's needed. When you reach the area where the material is needed, follow the spotter's directions. If you don't have a spotter, raise the bucket slightly so you can see the bottom of the bucket and the ground. Open the clamshell slightly. Material will start to flow onto the ground between the bucket segments.  Gradually increase or decrease the loader's speed. Depending on how thick a spread is required, adjust the bucket segment opening accordingly. At the edge of the low area, close the segments. If you still have material in the bucket, pull forward for another pass across the low area. This method works well when spreading thin lifts of material such as topsoil or sand over sod or grass. The loader tires won't be running over and compacting the material being spread. The result of this effort produces a pretty smooth fill. To really finish this effort, a little back dragging is all that's needed. If you're out of material, refill the bucket for another pass. This time, instead of backing across the low area, we're going to spread with the front end loader traveling forward. Position the loader bucket at the edge of where the material is required. Once again, raise the bucket slightly so you can see the bottom of the bucket and the ground. Open the clamshell slightly so the material will flow onto the ground. Move the front end loader forward slowly while gradually filling the low area. Proceed across the low area in this manner until your signal does stop. You may have to make a number of passes across the low area depending on the size and depth of the fill. With this spreading technique, we tried to level the area using the bulldozer bucket position. As you can see, this technique takes a lot of practice to be real proficient. So the back dragging technique was again employed with fine results. The next spreading technique would be applicable if your front end loader was equipped with a standard bucket. However, this technique can be used with either type of bucket and can be accomplished driving the loader forwards or backwards. Load the bucket and proceed to the area requiring the fill material. Stop the loader and raise the bucket just high enough to see under it. It's hard to see how much you're spreading if you can't see the ground. Place the front end loader in reverse and uncurl the bucket in small jerking movements to shake the material out of the front of the bucket. Slowly back across the low area. As the front of the bucket tips forward, raise the bucket slightly and keep uncurling the bucket as you move backwards. At the end of the pass, curl the bucket back. Return to the beginning of the area requiring the fill for another pass. Continue this spreading technique until the low area is filled. It's hard to get a real smooth even spread with this technique. You'll more than likely have highs and lows in the material just placed. Back dragging the area can easily level this fill and dress up the area. Spreading material using the techniques just described will significantly improve the serviceability of this unpaved road. Backfilling ditches and trenches can be accomplished with a number of pieces of construction equipment. The dozer, grater and front end loader can all be used to backfill. Each piece of equipment has advantages and disadvantages for this particular task. The dozer can handle large quantities of backfill material but cannot operate on hard surfaces such as asphalt. For real long backfill operations, the grater would be a good choice but it can move only small quantities of material with each pass. Numerous passes will be required to complete the backfilling operation. So for a piece of equipment that can operate on all types of surfaces and still handle large quantities of backfill material, the front end loader is probably the best choice and most versatile. Backfilling operation can be accomplished with a wheel mounted or track mounted front end loader using either a standard or multi-segment bucket. We'll cover both bucket techniques in this lesson. Before we cover the different backfilling techniques, let's talk about a safety issue that's bound to surface. Keep the front end loader out of the ditch or trench. Pushing the material back into and over the ditch will produce soft, loosely compacted material that generally won't support the weight of the loader. Keep the tires away from the edge because they will easily collapse the sides and may crush the items installed below. Getting a front end loader out of a ditch could take hours. Let's cover the bucket backfilling technique that can be used with a standard or multi-segment bucket. Position the front end loader at a 90 degree angle to the ditch or trench. Place the bucket in the bucket position and lower it to the ground. Slowly move the front end loader forward until it moves squarely into the pile of stock piled material. Fill the bucket but do not spin the tires. Continue the forward movement until the bucket is centered over the ditch or trench. Raise the bucket until you have a clear view of where the material will be deposited. Slowly tilt the bucket forward. If the material is not centered, move the loader forward or backwards until it is centered. Place the bucket back in the bucket position and back up to reposition the loader for another pass. Continue this sequence as you backfill the ditch. Make sure the bucket is centered and rotate it over until all the material has been emptied from the bucket. If the front end loader acted like it's going to stall, you may be trying to move too much material at one time. In this case, position the front end loader so that only half of the bucket will enter the pile of stock piled material. This bucket backfilling procedure can be used in most situations. Another technique you can use is to fill the bucket with material first. Approach the stock piled backfill material with the bucket level and just skimming the ground. Push the material forward into and over the ditch line. Do not empty the bucket. Raise the bucket slightly, back up and reposition the loader for another pass. This technique is a little faster because you don't have to empty the bucket on each pass. Either bucket technique will work just fine. It's a matter of adapting whichever technique works the best for your particular situation. Now let's try a technique that can only be accomplished with the multi-segment bucket. This backfilling technique is very similar to the leveling procedure covered earlier in the video. It's hard for the front end loader operator to accurately judge the bucket action in this procedure. A spotter will help ensure accurate material placement and speed up this backfilling effort. The front bucket segment must be opened all the way up. Place the bucket position indicator in the dozer position. Position the front end loader at a 90 degree angle to the ditch or trench. Lower it to the ground and move forward until the back of the bucket moves squarely into the pile of stock piled material. Continue moving forward, pushing the material into the ditch. As you reach the edge of the ditch, raise and tilt the bucket forward slightly to help slide the material off the back of the bucket. Back up and reposition the loader for another pass. Don't forget to set the bucket back to the dozer position before moving into the stock piled material again. As you move forward, keep an eye on the edge of the ditch. It's easy to accidentally drive into the ditch. Continue down the ditch line with the backfilling operation until it is completed. Each backfilling operation is different. Sometimes you'll be short of material. If you're short backfill material, additional material will have to be brought in. Other times you'll have an excess amount of fill material. Excess material should be placed over the ditch line to allow for settling action. Some ditches and trenches will require the fill material be compacted in layers while others won't need any compaction. Likewise, driving over the excess material may be all that's required on other fills. There's nothing worse than leaving the construction site a mess. Clean it up. Level or back-drag the ditch line to knock down any loose material and make the area look presentable. When backfilling around buildings and foundations, use extreme caution. Do not use the dozer method because the front bucket segment can easily hit the structure. Backfilling can easily be accomplished utilizing the different techniques just discussed. When the material is stockpiled beside the ditch, just push it in utilizing the bucket or dozer techniques. If the stockpiled material is located away from the ditch, the load, carry and dump technique would be the best choice. As you can see from the information presented in this program, the pavements and construction equipment operators can use the wheeled, mounted front end loader to accomplish a variety of projects. They include leveling an area, stockpiling material, spreading material, and backfilling a ditch or trench. This versatile piece of equipment is used almost daily. Just let it go in the shop for maintenance and you'll soon realize just how important it is. A lot of hand work will take its place, so take every precaution to keep it operating. Civil engineers can't afford to be without this key piece of construction equipment. This program was produced for headquarters, Air Force Civil Engineer Support Agency, Operations Support Directorate, Training Division. We gratefully acknowledge the 96th Civil Engineer Group, Horizontal Repair Section, Eglin Air Force Base, Florida for their support in producing this program.


This 10th year of Daily Tech News show is made possible by its listeners. And that's you right there. Hey, thank you for listening. Maybe you're Howard Yermish, John Atwood, Pat or brand new patrons. Everybody welcome in Daniel, Ulysses and Tony. On this episode of DTNS, the US issues, AI rules, but are they all for show? Meta is going to start charging Europeans for Facebook and how to turn noise canceling headphones into heart monitors. Magic. This is the Daily Tech News for Monday, October 30th, twenty twenty three in Los Angeles. I'm Tom Merritt and from Blackpink's Jenny Studio. I'm Sarah Lane and I'm the show's producer, Roger Chang. I'm sorry, what? I thought I'd throw you for a little Monday, Tom. You did. You got to keep you on your toes. No more disco napping. Panderin for the Blinks. Let's look at that. You and I from from Jenny doing quite well out there. So congratulations to her on that solo effort. Apple's having a Monday evening announcement, so we'll be covering those on our Tuesday show. If you're listening to this later, that's why you're not going to hear about that yet. But let's see what's in our Monday quick hits. Western Digital announced it will separate its flash business from its hard drive storage products into two discrete entities in the second half of next year. You may recall that Western Digital bought flash memory manufacturer Sandisk back in 2016. The Wall Street Journal notes, though, that this move effectively reverses that whole merger and spins off the flash division into a standalone business. Yeah, so they're going to sell off the flash memory business is what that seems like. That is what seems to be implied here. Got some good Microsoft news. Windows 11 2 to H2 now natively supports several new archive formats. So if you're a fan of raw or seven zip tar and GZ archives and a few others, you can just click on them. No need to do anything else. It does not, however, support password encrypted archive files. You'll need to bring in some third party support if you want to do those. You can get it now or wait for it to be rolled out throughout November. Less good Microsoft news. The company started showing error codes if you connect a third party controller to the Xbox that is not part of Microsoft's designed for Xbox program. If it's part of design for Xbox, third party controllers fine. If it's not, the error code tells the user they have two weeks to stop using that controller before it will be blocked. Microsoft recommends returning such controllers to the seller. That's their mitigation of like, yeah, get rid of it. Unauthorized controllers can sometimes be used for cheating, whereas unauthorized controllers also don't make Microsoft any money. Open AI rolled out a new feature for its pain. Chat GPT plus users that lets them upload files. This is a feature already available in chat GPT enterprise. So you might have played around with it. But if you haven't, when you give it a file, chat GPT can summarize it, answer questions about it and generate data visualizations. So let's say you upload a PDF or a data file or really any document. With multimodal support that would include an image as well. Qualcomm held a live benchmarking session for reporters to show off how well its new PC processing platform, the Snapdragon X Elite runs. The platform is based on Qualcomm's ORION CPU, which was built by engineers who previously worked on Apple's A series chips. And the benchmarks were really good outperforming Intel, Ryzen and a lot of cases, Apple's M2 chips. However, that comes just as Apple is announcing new chips. So, you know, your mileage may vary. How long that comparison lasts? Meanwhile, another chip news. Asus released a dual RTX 4060 Ti with an integrated PCIe M2 SSD slot. PC Gamer notes that lets you add an SSD in a PCIe lane that would otherwise be taken up by the graphics card. So that's kind of nice. And it will be in a better position for cooling. If you're using a motherboard with the M2 slots are located underneath the graphics card. Mastodon has added lists as a feature in its Android app. So if you're using the Android app or Mastodon or an instance, rather, you can create lists and then categorize them on topics or interests. A redesigned homepage also makes it easier to navigate between your feed and hashtags and the new lists feature. No word on when this might come to iOS, though. Hmm. They're working on stuff for iOS. That's all they said. All right, let's talk about the president. Yeah, so US President Biden, perhaps you heard of him, issued an executive order. This was expected today meant to manage the risks of developing AI. So, Tom, let's go through what it actually says. All right, we're going to ping pong this. It requires large developers to share safety test results and other critical information with the government. President used the Defense Production Act as a justification for this order. It would only apply to the largest developers. So we're talking open AI, Google, Meta, NVIDIA, maybe Adobe. It'll require the US National Institute of Standards and Technology, a.k.a. NIST to set, quote, rigorous standards for extensive red team testing to ensure safety before public release and, quote, the Department of Homeland Security and the Department of Energy will use their existing authority to encourage adoption of these standards for critical infrastructure. All right, they're going to make screening for AI risks a condition for federal funding of life science projects. You want to get the federal funds? You got a screen as a way to protect against dangerous biological materials. The Department of Commerce also getting involved, developing content authentication and watermarking guidance for federal agencies to use to show which communications are real and not AI generated, adding AI tools to find and fix security vulnerabilities other than the existing AI cyber challenge. So they're going to add that to the AI cyber challenge. But that would make sense. The order is meant to support research to protect people's privacy in training data and take other measures to encourage privacy protection in AI, both in and out of the government. Provide guidance and training about how to keep from using AI in a discriminatory way in housing and law enforcement. The Department of Health and Human Services will establish safety programs and take complaints on the use of AI in health care. They're going to create some guidance for teachers, provide guidance on preventing the use of AI from harming workers and also issue reports on impacts in the labor market. Encourage the use of resources and training for AI and research. And promote responsible use of AI abroad. And there's some more in there on setting safe standards for the use of AI by the government while encouraging government agencies to use it to improve costs and efficiency, encouraging hiring AI professionals. You notice there's a lot of guidance in here. Executive orders are not law. They cannot make or change the law. And executive orders can be challenged if they're seen to overstep the boundaries of the laws they use as their justification. Also, a new president can quickly rescind them. They don't stay on the books like a law does. Reuters saw the G7's document on a voluntary code of contact for AI. So that goes along with that. The G7 is Canada, France, Germany, Italy, Japan, Britain and the US, plus the European Union. So with that and the UK summit set for the middle of this week, it's a big week for talking about regulating AI. Sarah, this is a lot of stuff coming at once. Who do you think benefits from all of this? Well, I think we all potentially benefit from this. I didn't see anything in this executive order that, you know, made the hair stand up on my neck, so to speak. I thought, yep, that sounds good. Yeah, that's kind of vague, but sounds good. Yeah, that sounds really vague, but also sounds good. I think certain departments from within the administration being tasked with, you know, coming up with solutions, or at least following them closely, is not going to harm anyone. I think the more knowledge we have about what's going on, the better. I know that the executive order also doesn't, you know, roll back any rules that current AI systems are using. It's going to force companies, if they think that they're going to get in hot water, if they, you know, don't play nice with the government, to perhaps rethink some things that might be cool, tech-wise, but not necessarily great for humanity long term. So, you know, I wish I had a better answer for this. I think a lot of this is, let's start this conversation for realsies. That's what this feels like to me. And I don't think that's a bad thing. I just don't know exactly what changes from here. We need legislation. That's the long and the short of it, especially regarding training data. You know, there's some guidance in here about privacy and making sure people know about training data, but it's fairly toothless and fairly vague when we need comprehensive legislation, in my opinion, anyway, to set the ground rules to say, like, oh, if you're going to use data for training AI, here are the rules. Here's who you have to get permission from. Here's when you don't need to get permission because that's an entirely new situation. And there's a lot of other safety issues like that. That said, I don't have a problem with any of these. A lot of it is just good. Like, yes, we should have guidance. And I guess it depends on how good the guidance is. Right. Yeah. If the guidance isn't good, then this is bad. But if the guidance ends up being valuable, then that's fine. But no, it also doesn't force people to do the right thing. It's just guidance that that's always the nature of guidance, right? I mean, I would not even pretend to compare something like AI technology to net neutrality. But having the latter be a ping-pong issue in the government for some time now, what would be great is if we all kind of go, OK, so here's here's how AI is going to help us and not, you know, crush the world and not have the sort of like, well, that was the law a year ago and then we got a new president and now we got a whole other thing going on in the end. You know, it makes it more convoluted for the rest of us. Yeah, there's a lot of knee-jerk responses you could have to this, like, oh, this is just political trying to win votes. Oh, it's companies trying to preserve their competitive advantage over new companies by putting a lot of regulations. It's called regulatory capture. Put a lot of regulations in now that they can afford to comply with them. I don't see much of that here. The largest amount of paperwork is applied to the largest companies only. And and these are these are, again, fairly mild. Now, I would beware of regulatory capture, because I do think open AI and Google and Meta are all pushing to get regulations put in place that will make it harder for others to compete with them. I think there needs to be some honest discussions about safety and what's actually dangerous and what's actually not so that you're not doing regulatory capture, but you are contemplating, you know, what unforeseen side effects might happen. And like I said, I think we need read legislation. But all of that said, like, even with those knee-jerk reactions, this is not the worst example of the kind of thing that I would be worried about. So I think on the whole, it's benign, maybe is how I describe it.  AI companies should do what they want. End of story, gavel. Right. That would be an issue. So it's an element of the conversation. This is not the end of the conversation, but it's an element. Right. All right. Let's talk about this technology, which I find fascinating. Google has announced research into audio plethysmography. So we'll call it APG for short. It uses hardware for active noise cancelling to sense your heart rate, meaning it can turn any set of noise cancelling headphones into heart rate monitors with a soft rate, software upgrade. The ones you've got could become heart rate monitors. It works by sending a low intensity ultrasound signal into the ear, and then the active noise cancellation mics can detect the echoes of the sound off the ear canal that they're designed to do stuff like that. Tiny movements of the ear canal skin that are caused by blood moving through your your skin changes how the sound echoes back in a very small way, but it changes them and the software can use the variations detected to tease out what your heart rate is and even your heart rate variability. It works with music playing. So it doesn't matter if you've got music playing. It can still detect these differences because it can just cancel out the music. And even if the seal isn't great, it can also cancel out the noise that's leaking through. It does have to adjust for body movements. That is one thing that can throw it off. So Google says they are using a multi tone approach to kind of calibrate and adjust for that sort of thing. But in a study they did, 153 people had consistent accuracy, like less than four percent problem. So so pretty high accuracy. Not something you'd use in a clinical setting, maybe, but but enough to kind of tell you as you're walking around. We might be honest here. Yeah. Yeah. Well, so the only noise canceling headphones that I use, but I use them daily or the AirPods Pro that I bought earlier this year. And I use the noise canceling not all the time, but the majority of the time. And I also wear an Apple Watch. But if I was monitoring my heart rate, which that's just part of my health data that I find interesting. But if I was really looking at it closely and for whatever reason, I either didn't have a smart watch or I didn't always want to wear one. And that was the metric I was going for. This is awesome.  I can see where and I never really thought about it this way, but I can see where, especially when one might be out and about the that kind of, you know, blood rushing to an ear or not rushing, but, you know, giving an indication of of what's going on with the heart makes a lot of sense. I don't exactly know how, I don't know, is there a firmware update that makes this all possible at some point with existing noise canceling headphones that people might have over, you know, using various vendors to buy them. I don't know, but I I love this. I mean, this is all just like, let's let's reimagine data that we actually need. Some people, this data is extremely important. For other, you know, I don't have any heart problems that I know of. So this is more sort of like interesting and good to take, you know, keep an eye on type thing. So if there ever was anything weird, I would know more about it later. I think again, everybody wins here. Yeah, there are lots of headphones out there that have built in heart sensors because there are people who are like, they don't they can't afford to buy a super cool smart watch or don't like you said, don't want to wear a Fitbit, but they just want the heart rate. And especially if you want it while you're jogging, a lot of people wear headphones while they're jogging. Boom, there you go. It's a it's a simple thing. So yeah, this isn't going to replace fitness monitoring from your wrist, but it is an interesting thing to have. And it is something that is easily added to existing headphones and turns them all into heart rate monitors, making it more compelling. I don't have to buy a special pair of headphones to get it. Exactly. So yeah, I think that I think this is this is cool. You hit on the big question, which is so Google, are you going to make this easily available for Sony and Apple and others to use? Are you going to hoard it to yourself? Are you even going to roll it out to your own earbuds? Like the Pixel Buds, we don't have any kind of sense of that. This is just the study to say, hey, it looks like this works. Right. I don't know when this rolls out into a product, but I would like it to be soon because I think it's cool too. Me too. Me three. Well, do you think it's cool? Tell us on our subreddit as well as telling us other stories like this one that you'd like to hear us talk about. We've got a great subreddit community in there. So go over and take a look at it. You can submit stories and vote at DailyTechNewsShow.Reddit.com. Back in January of this year, the European Union determined that Facebook, owned by Metta, could not claim a contractual necessity for much of the personal data that it collects on its users. Under the GDPR, any collected info that isn't strictly necessary has to be collected by user consent that is informed specific and freely given and are really handed down by the court of justice of the EU. Judges advised that an appropriate fee could be collected for equivalent alternate services that don't track users. This was non-binding, but it was an element of the court's decision. Metta is using this to justify its next approach. Right, Tom? Yeah, it's a little shaky ground, right? The court just said, maybe you could do this. They didn't rule that you could do it. So I'm going to spoiler alert. The end of this story is everyone's going to take Metta to court and we're going to rule on this again. But here's the situation as it stands now. Users in the European Economic Area. So the European Economic Area is the European Union plus Iceland, Lichtenstein and Norway. So the European Economic Area and Switzerland, which is not part of the European Economic Area, but it's part of this policy from Facebook. If you agree to be targeted by ads, you can continue to use the service for free. So what Metta is saying is on Facebook and Instagram, we will give you informed consent. We will tell you we're going to track you in these ways. Is that OK? If you say yes, keep using it for free. If you say no, you either don't use the service. You just say, nope, I'm not going to use Facebook or Instagram or you will be given the option to pay nine euros, 99 cents a month, 10 euros a month. Or if you're signing up through Google or Apple stores where they take a cut, it'll be 13 euros a month. After March 1st, 2024, they're going to start charging you for linked accounts. So if you have an Instagram account and it's linked to your Facebook account, you won't have to pay 10 euros a month for both. Your linked account will cost you either six euros or, again, if you're going through the app store, eight euros a month. Ads for users younger than 18 will be paused. So the charge is only if you're older than 18. If you're younger than 18, you will not have to see ads or pay starting November 6th. Metta says that cause will last while it evaluates the impact of new EU regulations, and they'll have more details on options for younger users in the coming months. Now, this hasn't been tested in court, nor has it been approved by the Data Protection Commission. Ireland's Data Protection Commission has jurisdiction over Metta because Metta's headquarters are in Dublin. It is still evaluating this plan. Metta gave it to them, but Metta said we're going to put it in place in 2024. The Irish DPC said, we think you should put it in place faster than that. Metta said, OK, we will, but the DPC hasn't finished evaluating itself. It could conceivably come back and say, no, this isn't OK. But even if it comes back and says, yes, this is fine, I would expect Max Shrems and his organization to take Metta to court and say, this is too much money. This is not what we had in mind. What do you think, Sarah, is 10 euros a month an appropriate fee to get Facebook without ads? Well, I wouldn't pay. I wouldn't pay that, which is, you know, let's just say it was 10 dollars a month, which is not too far away from it. It's good. Yeah, euros and dollars are fairly close. Exactly. For Facebook, I'd be like, I don't care about Facebook that much. But if you say that for Instagram, I might go, huh, well, I really, really hate ads on Instagram, but I also use Instagram on a daily basis. Well, my dog uses Instagram on a daily basis. Otis is a prolific user of Instagram, right? Yeah, you know, I'm his guardian. So you might have to pay 10 euros for each your and Otis's accounts. Yeah. And that's where it kind of gets fuzzy to me. I wonder how much, listen, I know Metta is trying to, Metta knows that there are legal battles ahead. And for the company to say, OK, well, for those of you who do not want to be targeted by ads and maybe we're just going to bounce out, maybe some of you will pay. And for that, let's see how many people do do that and the rewards that we reap financially. I think this all is going to get torn apart sooner than later. I don't exactly know how it just seems too easy.  Eventually, you know, it doesn't matter where you live in the world. That's not what's going on here. You just have to agree to what was already happening. And you can either say, no, I don't like this place. I'm going elsewhere, which you always could do or say, actually, you know, how about an ad for experience? That could be a fun, you know, way to stay on a platform that, you know, all my friends and family are still on or at least a way to give it a shot. I don't, you know, I don't live in the EU, so this doesn't apply to me. But this would be something I would try for a month, 100 percent. It's clear to me that Metta doesn't want to use this to make money. I've seen I've seen a lot of people say, oh, this is a cash grab. If that was the case, they would be going to get enough cash for it to be. No, they're not. And they would be rolling at it. They'd be talking about like, well, and if it goes well in Europe, we might roll it out elsewhere. They're not. They very clearly said, this is only going to happen in Europe. We're only doing it because we have to. So the big question is going to be whether the courts will say, this is an inappropriate fee at which point, what is the appropriate fee? Is it five euros? And is that enough for Metta to go? OK, it's we don't want to leave the European market. So fine, we'll take a loss on the people that sign up. Maybe it won't be that many. They've obviously figured out that 10 euros is going to keep them from losing money. I'm guessing it's got a little padding in there so they could probably go down a little bit. But what is that number? Is there a number? I have a feeling that that Max Schrems group is going to say they shouldn't make you charge at all. That's not freely given consent if your only other option is to pay. I'm not sure I'd buy that, though, right? Because you pay to get rid of ads and lots of things. Like, why should Facebook be prevented from offering that? Yeah, I mean, that is one of the huge issues that people have with. Well, I was about to say Facebook, but Metta in general. I think this is potentially something that will appease a lot of users. Maybe not anybody who works, you know, in the government sector. But but yeah, let's let's let's see what happens. If you live in one of the areas affected and you're, I don't know, if you're under 18, that would affect you as well. But if you're over 18, well, that's the thing, right? Can you just say I'm under 18 and get away without ads? You can. You might get caught. And it also restricts what you can do. So exactly. You may not be worth it to do that. Right. Right. I know when I was like, oh, for every additional account associated with Facebook, I'm like, oh, this is younger than 18. Yeah. But I mean, I also have like burner accounts that sure. I mean, if somebody really wanted to go after me, they could figure it out. But like, I'm not telling them that that's my other Facebook account and paying more. Come on. Yeah. Agreed. Well, what Max Shrems and the Noeva Group, and why be are our regular folks that are going to fight this on your behalf, Europeans, if you don't like this. Meanwhile, in Japan, giant robots are going to fight on your behalf. Yeah. At Japan's mobility show, Yokohama based Subame showed it showed off something called the Arch Axe, a three million dollar transforming Mecca, meaning a large armored robot. Now you might say, well, that's crazy. What in the heck? This one doesn't really do much besides left its arms, wave to the crowd and go between robot mode and vehicle mode. This part is actually pretty fun. So the Arch Axe, which only has five sellable models, mind you, has four legs, each with a wheel at the bottom driven by an electric motor. So, you know, it's a car in vehicle mode. The legs are spread apart, lowering the center of gravity. It can it can reach a blistering top speed of six miles per hour. So, OK, it can move. But transforming to robot mode takes about 15 seconds, where then the machine rises to a height of 15 feet. Uh, uh, mobility show event goers have said it's pretty cool and it's real big. Finally, the cockpit is accessed through four separate hatches, which open and sink, revealing the pilot's chair, just the one chair. Once the models are sold out, Subame wants to create a robot league where the models fight each other. And you might say, well, that's a really bad idea, right? Especially when humans are inside, it's only supposed to be in VR. This is now this is like a concept car for mechos.  Gundam and everything, the closer they can make them to being real, the more likely somebody is to try to make them. And so this doesn't surprise me too much. But Roger, you follow this really close.   So this totally reminds me of back in 2016. There was a whole or 20, 2015, 2016. There was a whole thing where Megabots, Incorporated, based down in Hayward, or up for me, up in Hayward, California, challenged the Japanese Serobashi Heavy Industry, who also created a very similar robot to a robot versus robot duel. And to me, this kind of is half kind of tongue in cheek, like we're going to create a giant robot. Other half of but the other half is creating the technology that allows you to kind of have a large, heavy and somewhat awkward shaped piece of machinery amble about without keeling over and crushing someone. This is I don't want to say this is totally a promotional stunt, but it's it's a pretty cool promotional stunt. It's a love of giant robots first, then promotional stunt second in order to try to make enough money to justify doing the thing you did because you love giant robots. That's how I guess it is. It is definitely kind of a self-referential campaign. I feel like I'm indifferent to giant robots. You know, Roger, you said who doesn't love them. Are you sure you want to say that on the Internet, Sarah? Well, I don't I. Yes, I am sure. You know what? You're not the boss of me, but you're sitting. We I'm indifferent to them until they really are fighting each other. And then I'll have some thoughts when you're sitting in your own very, very own 30-foot Sarabot that you get to control like I don't want to do that. I mean, maybe you say that now, say that now. Oh, my gosh. You guys, OK, you know what? When the apocalypse hits, I'll be I'll be getting in there and watch out world because I will not be fighting in VR. This is no, I know. I think that VR training for you, Sarah. Now you we need some regulations on giant robots for the exact. Biden, where are you when we need you? All right, let's check out the mailbag. Let's do it on Friday's GDI. We were talking about whether we would like to look into the future or the past if we had to choose one that inspired Allen to post a comment on Patreon. Allen said the time travel discussion reminds me of a story by Ozzyk Asimov called the dead past. He says spoilers incoming. This was written a long time ago, so I think we're OK. Allen says roughly it's about some people who invent the ability to look back in time, but they get shut down by the government. At first, all the viewing was distant past. But as they got closer, they got government interference. The reason is that the past ends a split second ago. So basically the device was the ultimate spine device, which is why the government stopped them and also how it thwarted their plans.  And I'll always remember this one. That is a really interesting premise because broadcasts are much more delayed from live than they used to be. When everything was over the air, there was a little bit of delay between something happening and you seeing it or hearing it, but not much. Of course, now over the Internet, there's so much more latency in there. I actually heard that the CBC has has ended its one o'clock PM long dash, which was meant to let everyone in Canada calibrate their clocks to know exactly when it was one PM Eastern time because digital broadcasting means that it doesn't happen at exactly the right moment that it should anymore. It's not that is good at calibrating. I thought everybody in Canada had had to run in a dash. Now, yeah, now they all have to do a hundred meter dash. Yeah, that's us. No, I'll get you. But but that idea of like if you look into the past, the past is just a split second ago. Yep, there you go. All right, folks, if you like these kinds of conversations, we have them in good day. Internet patrons get the extended show, stick around. The phone maker, nothing has put out its own beer. Now, granted, they partnered with a brewery. Like, yes, it's it's a publicity stunt. But we have a report on how it is is a decent beer. And we started thinking about what drinks other companies might want to put out. Perhaps Apple, Andrew Langston from CNET, suggests might want to put out a vodka. We're going to talk about it, stick around. And that sentence by Tom is now in the past. You can also catch the show Monday through Friday. We do it live. 4 p.m. Eastern 20 hundred UTC for a little bit longer. Anyway, find out more at DailyTechNewShow.com at slash live. That URL is there. It's just that there's a time change looming in the US. We are back tomorrow with Charlotte Henry joining us. Talk to you then. This show is part of the Frog Pants Network. Get more at FrogPants.com. The Diamond Club hopes you have enjoyed this program.