DEV Community: Patrice Gauthier

It's time to ditch the complicated and slow Python setup

Patrice Gauthier — Thu, 11 Jul 2024 14:03:06 +0000

At my work I was faced with a complicated installation process for Python. The Python version of the project was older than the one shipped by my OS. I've wasted a morning to set it right. So I've wondered if there was a more straight forward way to install it and if there was a more developer friendly approch to managing dependencies than manually setting the version in requirements.txt. I've looked for a solution and I found one. It's called Rye.

Rye: The Modern Python Project Management Tool

Rye is an awesome project management tool for Python that aims to simplify dependency management and project set-up. It offers a user-friendly approach to handling Python projects, making it easier for developers to manage their work efficiently.

Key Features of Rye

Simplified Dependency Management: Rye streamlines the process of managing project dependencies.
Virtual Environment Handling: It automatically creates and manages virtual environments for your projects.
Project Initialization: Rye provides easy-to-use commands for setting up new projects or integrating with existing ones.
Consistent Environments: Ensures consistency across different development environments.

Setting it up in a New Project

To start a new project with Rye, follow these steps:

Install it: Follow your OS instructions. It will ask you which shims you want to use (choose the one of Rye's) then which Python version to use as it manages python versions.
Initialize a python project:

   rye init <directory_name>

This command will create some files including the new pyproject.toml configuration file.

Install the initial dependencies:

   rye sync

Running this command set up a virtual environment for your project as .venv and install the dependencies specified in the pyproject.toml. It uses uv by default (it's own Python tool for handling dependencies written in Rust) or pip-tools. Notice that there's no requirements.txt. It's all handled by Rye now using lock files.

Add Dependencies: Use Rye to add any necessary dependencies:

   rye add package_name

Sync again to install dependencies

   rye sync

That's it!: Just repeat the sync step when adding dependencies or modifying the project file!

Integrating Rye into an Existing Project

If you have an existing Python project that uses a requirements.txt file, you can easily move to Rye. Here's how:

Initialize Rye with Existing Requirements:

   rye init -r requirements.txt

This command will:

Create a pyproject.toml file and include your dependencies in it.
Set up a .venv virtual environment (or it will asks if it exists already)

Review and Adjust: Check the newly created pyproject.toml file and make any necessary adjustments. Delete the requirements.txt as it is unused.
Update Your Development Process: Start using Rye commands for managing dependencies and your development environment.

Using Rye to manage Python versions

Rye is your main tool to manage the python ecosystem.

Best Practices When Using Rye

Use rye run to execute scripts in your project's environment
Leverage rye add and rye remove for managing project dependencies
Commit your pyproject.toml file to version control, but exclude the .venv directory

A 15 min walktrough by the author

Conclusion

Rye offers a modern and efficient approach to Python project management. Whether you're starting a new project or integrating it into an existing one, Rye simplifies many aspects of Python development. By following the steps outlined above, you can harness the power of Rye to streamline your Python project workflow.

A hidden power tool for arrays in TS

Patrice Gauthier — Thu, 25 Jan 2024 19:20:48 +0000

I am a fan of functional programming. The domain can be very complex but some the parts are simple. Even so that a lot of developers probably don't even know they are using functional programming. Some developers do not like to use functional programming because of how much memory it takes to respect immutability specially in the case of arrays but this library can help use functional programming in Typescript in an efficient way.

This library is FxTS.

Unlocking the power of lazy evaluation

FxTS introduces a novel approach to array manipulation compared to the default ones when using map, filter and such by introducing the concept of lazy evaluation. Unlike traditional methods that demand iterating through entire arrays regardless of necessity, FxTS uses generators to go over array elements. This means the iteration only occurs when values are explicitly needed, optimizing resource consumption and significantly boosting performance.

Let's compare how it behaves compared to the traditional Array functions like map, slice, sort, etc.

Say you want the top 5 elements of an array. When we use the Array functions we go over all the elements many times.

[1, 2, 3, 4, 5]
  .filter((a) => a % 2 === 0) // [2, 4, 6, 8]
  .slice(0, 2); // [2, 4]
  .map((a) => a + 10) // [12, 14]

Using FxTS we process only the until the two elements that satisfies the filter. This can make the difference when the array is large.

pipe(
  [1, 2, 3, 4, 5],
  map(a => a + 10), // [12, 14]
  filter(a => a % 2 === 0), // [12, 14]
  take(2), // [12, 14]
  toArray
);

Here's an example of how it evaluates.

The awesomness of generators

At the core of FxTS lies the ingenious use of generators, a feature intrinsic to JavaScript. By embracing generators, FxTS provides us with a gateway to seamlessly handle infinite values within arrays. It's like having a superpower when dealing with vast datasets or scenarios where continuous, endless streams of data must be efficiently processed.

Here's an example that is too simple but helps to see how it works.

pipe(
  range(Infinity),
  filter((a) => a % 2 === 0), // [0, 2]
  map((a) => a * a), // [0, 4]
  take(2), // [0, 4]
  reduce(sum), // 4
);

Handling promises

FxTS allows to easily handle promises sequentially and concurrently. The benefit is really in the latter.

const fetchMovie = async (year: number) =>
  fetch(`https://api.movie.com/${year}`);

const moviesByYear = async (year: number, howManyYears: number) =>
  pipe(
    range(year, Infinity),
    toAsync,
    map(fetchMovie),
    map((res) => res.json()),
    take(howManyYears),
    toArray
  );

await moviesByYear(2020, 3);

Here's an example where a RapidAPI is actually called to get the movies for a year. Error handling is the same as ever using try catch.

    type Movie = { imdb_id: string; title: string };
    type APIResponse = {
      links: { next: string; previous: string };
      count: number;
      results: Movie[];
    };

    const fetchMovie = async (year: number) => {
      console.log(`getting movies for ${year}`);
      return fetch(
        `https://moviesminidatabase.p.rapidapi.com/movie/byYear/${year}/`,
        {
          headers: {},
        },
      );
    };

    const getMoviesForYear = async (year: number) =>
      pipe(
        year,
        fetchMovie,
        (res) => res.json(),
        (response: APIResponse) => response.results,
      );

    try {
      return getMoviesForYear(2020);
    } catch (err) {
      console.log(err);
    }

FxTS allow to easily work with concurrent promises. Here's a sample of the code I've used in my Tiled Hacker news project. In this case promises are executed by batch of 10. In case of an error when calling getStoryById it's not blocking the execution of promises in the batch or the execution of other batches. It's up to you to determine if it's what you need.

  const { pageOfStoryIds } = await getCachedPaginatedStoryIds(
    "top",
    pageIndex,
  );
  const stories = pipe(
    pageOfStoryIds,
    toAsync,
    map(getStoryById),
    concurrent(10),
    toArray,
  );

In conclusion FxTS allows to easily work with array of sync and async data. It is a solid tool to work with arrays using the functional programming style.

Importing kubernetes manifests with terraform for cert-manager

Patrice Gauthier — Wed, 17 Jan 2024 15:37:53 +0000

How to import many Kubernetes manifests with Terraform.

This tutorial will focus on creating Kubernetes resources for cert-manager on Google Cloud though this could apply on AWS EKS.

Cert-manager needs CRDs (Custom Resource Definitions) to be defined in K8S as they do not exist originally and Kubernetes will reject them if you install the Cert-manager helm chart without it.

We need to do that in 2 steps but Terraform applies it all in one sweep. To solve this problem it can be achieved by using Terragrunt to manage Terraform folders each with their own state. With this we can apply the CRDs configuration first then apply the Cert-Manager helm chart.

Steps

The steps will be as follow:

Create the kubernetes cluster
Apply CRDs for Cert-manager
Install the helm release of your application (it should include the ingress or at least have the ingress defined before installing cert-manager)
Install the cert-manager helm release

Create the cluster

Define and create your K8S cluster to be managed by Terraform in a folder. (ex: 1-k8s-cluster/main.tf)

terraform {
  backend "gcs" {}
}

variable "cluster_location" {
  type = string
}
variable "cluster_name" {
  type = string
}
variable "environment" {
  type = string
}

data "google_project" "project" {}

resource "google_artifact_registry_repository" "docker_registry" {
  repository_id = "us.gcr.io"
  format        = "DOCKER"
}

resource "google_container_cluster" "k8s_cluster" {
  name                     = var.cluster_name
  location                 = var.cluster_location
  initial_node_count       = 1
  enable_shielded_nodes    = false
  deletion_protection      = true
  remove_default_node_pool = true
  networking_mode          = "VPC_NATIVE"
}

resource "google_container_node_pool" "pool-1" {
  name               = "pool-1"
  location           = var.cluster_location
  initial_node_count = 1
  cluster            = google_container_cluster.k8s_cluster.name

  node_config {
    machine_type = "e2-standard-2"
    image_type   = "COS_CONTAINERD"
  }

  management {
    auto_repair  = true
    auto_upgrade = true
  }

  network_config {
    create_pod_range     = false
    enable_private_nodes = false
  }

  depends_on = [google_container_cluster.k8s_cluster]
}

output "cluster_name" {
  value = google_container_cluster.k8s_cluster.name
}

output "cluster_endpoint" {
  value = google_container_cluster.k8s_cluster.endpoint
}

output "cluster_ca_certificate" {
  value = google_container_cluster.k8s_cluster.master_auth[0].cluster_ca_certificate
}

Create a Terragrunt file to refer to the root file.

include "root" {
  path = find_in_parent_folders()
}

Then define the root file in the parent folder

inputs = {
  envvars...
}

locals {
  project = "..."
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "google" {
  project = "${local.project}"
  region  = "us-east1"
}
  EOF
}

remote_state {
  backend = "gcs"
  config = {
    project              = local.project
    bucket               = "unique-bucket-name"
    prefix               = "${path_relative_to_include()}"
    location             = "us-east1"
    skip_bucket_creation = true
  }
}

The K8S CRDs folder

In one folder (ex: 2-K8S-Crds) you define those K8S manifests to apply before anything else.

in main.tf

terraform {
  required_providers {
    kubectl = {
      source  = "gavinbunney/kubectl"
      version = "1.14.0"
    }
  }
}

# The reference to the current project or a AWS project
data "google_client_config" "provider" {}

# The reference to the current cluster or EKS
data "google_container_cluster" "my_cluster" {
  name     = var.cluster_name
  location = var.cluster_location
}

# We configure the kubectl provider to use those values for authenticating
provider "kubectl" {
  host                   = data.google_container_cluster.my_cluster.endpoint
  token                  = data.google_client_config.provider.access_token
  cluster_ca_certificate = base64decode(data.google_container_cluster.my_cluster.master_auth[0].cluster_ca_certificate)
}

#Download the multiple manifests file.
data "http" "cert_manager_crds" {
  url = "https://github.com/cert-manager/cert-manager/releases/download/v${var.cert_manager_version}/cert-manager.crds.yaml"
}

data "kubectl_file_documents" "cert_manager_crds" {
  content = data.http.cert_manager_crds.response_body
  lifecycle {
    precondition {
      condition     = 200 == data.http.cert_manager_crds.status_code
      error_message = "Status code invalid"
    }
  }
}

# We use the for_each or else this kubectl_manifest will only import the first manifest in the file.
resource "kubectl_manifest" "cert_manager_crds" {
  for_each  = data.kubectl_file_documents.cert_manager_crds.manifests
  yaml_body = each.value
}

You define a Terragrunt file to set the dependencies

include "root" {
  path = find_in_parent_folders()
}

dependency "cluster" {
  config_path = "../1-k8s-cluster"
}

Deploy

Define the helm chart for your application. It may of may not have the ingress in it but the ingress should exist before installing the cert-manager. When cert-manager will be deployed, cert-manager will see the annotations on the ingress an do its thing (do a cert-request etc.)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/enable-cors: 'true'
    nginx.ingress.kubernetes.io/cors-allow-methods: 'GET, PUT, PATCH, POST, DELETE, OPTIONS'
    cert-manager.io/cluster-issuer: 'letsencrypt-staging' 
    certmanager.k8s.io/acme-challenge-type: http01
spec:
  #tls:
  #  - hosts:
  #      - 'your-domain'
  #    secretName: app-backend-cert-tls
  rules:
    - host: 'your-domain'
      http:
        paths:
        - backend:
            serviceName: my-app
            servicePort: 8080
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: my-app
              port:
                number: 8080

The cert-manager folder

In my case this folder is within the same root folder containing the terraform folders but it doesn't have a terragrunt file. I want to install cert-manager post deployment of the application (this is for CI).

data "google_container_cluster" "cluster" {
  name     = local.cluster_name
  location = local.cluster_location
}

#needed for inlining kubernetes manifest as terraform code (kubernetes_manifest resource).
provider "kubernetes" {
  host                   = "https://${data.google_container_cluster.cluster.endpoint}"
  token                  = data.google_client_config.provider.access_token
  cluster_ca_certificate = base64decode(data.google_container_cluster.cluster.master_auth[0].cluster_ca_certificate)
}


provider "helm" {
  kubernetes {
    host                   = data.google_container_cluster.cluster.endpoint
    token                  = data.google_client_config.provider.access_token
    cluster_ca_certificate = base64decode(data.google_container_cluster.cluster.master_auth[0].cluster_ca_certificate)
  }
}

#in my case I use it to create the tls secret with only the keys defined 
provider "kubectl" {
  host                   = data.google_container_cluster.cluster.endpoint
  token                  = data.google_client_config.provider.access_token
  cluster_ca_certificate = base64decode(data.google_container_cluster.cluster.master_auth[0].cluster_ca_certificate)
  load_config_file       = false
}

resource "helm_release" "cert_manager" {
  name             = "cert-manager"
  namespace        = "cert-manager"
  repository       = "https://charts.jetstack.io"
  chart            = "cert-manager"
  version          = var.cert_manager_version
  create_namespace = true
}

resource "kubernetes_manifest" "staging_cluster_issuer" {
  manifest = {
    apiVersion = "cert-manager.io/v1"
    kind       = "ClusterIssuer"
    metadata = {
      name = "letsencrypt-staging"
    }

    spec = {
      acme = {
        email = local.cert_contact_email
        privateKeySecretRef = {
          name = "letsencrypt-staging"
        }
        server = "https://acme-staging-v02.api.letsencrypt.org/directory"
        solvers = [
          {
            http01 = {
              ingress = {
                class = "nginx"
              }
            }
          }
        ]
      }
    }
  }
  depends_on = [module.cert-manager]
}


//ignore fields so that when it gets changed by issuers, it doesn't trigger a diff
resource "kubectl_manifest" "app_backend_cert_tls" {
  apply_only    = true
  ignore_fields = ["data", "annotations"]
  yaml_body     = <<YAML
apiVersion: v1
kind: Secret
metadata:
  name: app-backend-cert-tls
  namespace: my-app
data:
  tls.crt: 
  tls.key: 
YAML
}



resource "kubernetes_manifest" "prod_cluster_issuer" {
  manifest = {
    apiVersion = "cert-manager.io/v1"
    kind       = "ClusterIssuer"
    metadata = {
      name = "letsencrypt-prod"
    }

    spec = {
      acme = {
        email = local.cert_contact_email
        privateKeySecretRef = {
          name = "letsencrypt-prod"
        }
        server = "https://acme-v02.api.letsencrypt.org/directory"
        solvers = [
          {
            http01 = {
              ingress = {
                class = "nginx"
              }
            }
          }
        ]
      }
    }
  }
  depends_on = [kubernetes_manifest.staging_cluster_issuer]
}

Then in your ingress you comment out the tls section.
You should be able to connect to your application and if it's with the browser it will give a warning because the staging cert is self-signed. You accept it and it works!

To use the actual certificate now you just need to change the annotation to:
cert-manager.io/cluster-issuer: 'letsencrypt-prod'

Now with this you have a kubernetes cluster that runs cert-manager with the ease of changing its version.

3 powerful tools to ensure API integrity in Typescript

Patrice Gauthier — Fri, 21 Apr 2023 14:47:51 +0000

As the world becomes increasingly digitized, APIs (Application Programming Interfaces) have become a crucial component of software development. They provide a standardized way for different applications to communicate with each other, making it easier to integrate different systems and services. One of the challenges of working with APIs is ensuring that the data being sent and received is properly structured and validated. In this article, we will walk through the steps of using four powerful tools to achieve this: getting a JSON test response from an API, using quicktype to convert JSON to Typescript type, using Zod to write a schema following the structure of the generated type, and using ts-toolbelt to ensure that the Zod schema is the same or extends the generated type.

Step 1: Get JSON Test Response from an API

Before we can begin working with APIs, we need to obtain a test response that we can work with. In this example, we will be using the JSONPlaceholder API to get a test response. We will make a GET request to the /todos endpoint to get a list of to-dos. The response will be in JSON format and will look something like this:

[
  {
    "userId": 1,
    "id": 1,
    "title": "delectus aut autem",
    "completed": false
  },
  {
    "userId": 1,
    "id": 2,
    "title": "quis ut nam facilis et officia qui",
    "completed": false
  },
  ...
]

We will save this response in a file called test-response.json.

Step 2: Use Quicktype to Convert JSON to Typescript Type

Now that we have a test response, we can use quicktype to generate a Typescript type based on the JSON structure. Quicktype is a powerful tool that can generate types for a variety of programming languages and data formats, including JSON, XML, and CSV. It uses machine learning algorithms to analyze the structure of the data and generate a type that matches it.

To use quicktype, we can simply run the following command:

npx quicktype test-response.json -o todo.ts --just-types

Note: Quicktype has a VScode extension to paste JSON and convert to type

This will generate a file called todo.ts that contains a Typescript type that matches the structure of the JSON response. The contents of the file will look something like this:

export interface Todo {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
}

This generated Typescript type serves as documentation for the structure of the JSON response but this is only helps us when we code. We can do better. We can validate at run time.

Step 3: Use Zod to Write a Schema Following the Structure of the Generated Type

Now that we have a Typescript type that matches the structure of the JSON response, we can use Zod to write a schema that enforces the structure of the type. Zod is a powerful schema validation library that can be used to validate data against a schema in Typescript.

To use Zod, we first need to install it:

npm install zod

Next, we can write a schema that matches the structure of the Todo type that we generated in the previous step:

import * as z from 'zod';

const todoSchema = z.object({
  userId: z.number(),
  id: z.number(),
  title: z.string(),
  completed: z.boolean()
});

This schema enforces that the userId and id properties are numbers, the title property is a string, and the
completed property is a boolean, just like in the original JSON response. We can now use this schema to validate any data that we receive from the API to ensure that it matches the expected structure.

Step 4: Use ts-toolbelt to Ensure that the Zod Schema is Same or Extends the Generated Type

While we have written a schema that matches the structure of the generated Typescript type, there is still a chance that the schema could become out of sync with the type as our codebase evolves. To prevent this from happening, we can use ts-toolbelt to ensure that the schema is the same or extends the generated type.

To use ts-toolbelt, we first need to install it:

npm install ts-toolbelt

Next, we can write a type that takes a schema and a Typescript type and uses ts-toolbelt to ensure that the schema is the same or extends the type. We do that by writing below in a file that you do not execute. It only serves to highlight errors in VSCode.

import { A, Test } from "ts-toolbelt";
import { todoSchema } from "./schema"
const { checks, check } = Test;

type validation = A.Equals<z.infer<typeof todoSchema>, Todo>;
checks([check<validation, 1, Test.Pass>()]);

Now since Zod only validates at runtime it can't tell you in VSCode that the schema is wrong but when you compare the generated type with it and there's a mismatch VSCode will tell you about it. Also as example if you run it in a CI pipeline against a testing API you will know if the API has changed so you can update your code before they update their production API.

Conclusion

In this article, we have walked through the steps of using four powerful tools to ensure that the data we receive from an API is properly structured and validated. We started by getting a JSON test response from an API, then used quicktype to generate a Typescript type based on the response. We then used Zod to write a schema that matched the generated type, and finally used ts-toolbelt to ensure that the schema was the same or extended the type. By following these steps, we can ensure that our API integration is robust, reliable, and easy to maintain over time.

How to create composable forms using React Hook Form, Compound Components and Zod

Patrice Gauthier — Wed, 03 Aug 2022 03:01:28 +0000

In this article I will show you how to use advanced React concepts to have a form with reusable components, validation and have it share data between components. This will avoid abuse of prop drilling and of context while allowing to compose our form. It will be as much as it can be valid with Typescript.

Compound Components

First Compound Components is a way to explain to the reader there's a parent-child relationship between component. It makes it so that you have to define the parent before you define the child. There's a whole article about that on Smashing Magasine. Basically it allows us to have components like below where you know you have to create a Form component before using the inputs. The reader can also deduce those components are reusable.

<Form onSubmit={onSubmit}>
  <Form.Input name="firstName" label="First name" />
  <Form.Input name="lastName" label="Last name" />
  <Form.Submit type="button"/>
</Form>

Composing your form with reusable components

To make your form reusable, you have to create components that are reusable and also you should be able to compose your form as you need. For this React Hook Form provides a small example. Here's a screenshot of it.

There's a problem with this solution though. It creates every child component passing it the register function and so it requires that every child component is an HTML input or select.

This can be circumvented by using another API from their documentation.

Use form context

Using form context allows to create child components no matter how deep they are. You wrap your form with a <FormProvider> passing all the methods

export function Form({
  schema,
  onSubmit,
  children,
  defaultValues
}: {
  schema: any
  onSubmit: (data: Record<string, any>, event?: React.BaseSyntheticEvent) => void
  children: any
  defaultValues?: Record<string, any>
}) {
  const methods = useForm({
    defaultValues,
    resolver: zodResolver(schema)
  })
  const handleSubmit = methods.handleSubmit

  return (
    <FormProvider {...methods}>
      <form onSubmit={handleSubmit(onSubmit)}>
        {children}
      </form>
    </FormProvider>
  )
}

Now we can have an <Input> defined as below where we get the register function that is needed to link the input to the React Hook Form and some other state like errors and isSubmitting. With this error handling is within the component and the input gets locked when we submit.

Form.Input = function Input({
  name,
  displayName,
  type
}: {
  name: string
  displayName: string
  type: string
}) {
  const {
    register,
    formState: { isSubmitting, errors }
  } = useFormContext()

  return (
    <div>
      <label className="block">
        <span className="block">{displayName}</span>
        <input
          type={type}
          {...register(name)}
          disabled={isSubmitting}
        />
      </label>
      {errors[name as string] && (
        <p className="error">{errors[name as string]?.message}</p>
      )}
    </div>
  )
}

Assign a schema for validation

For this form to be reusable and valid we want to do validation on the inputs. React Hook Form provide their own simple validation but here we will use zod as schema validation. This makes the form ready to handle more complex validation.
Adding validation can be done by passing the validation schema to the Form component.

+ import { zodResolver } from "@hookform/resolvers/zod"
...
function Form({
+ schema,
...
}: {
+ schema: any
...
}
  const methods = useForm({
    defaultValues,
+    resolver: zodResolver(schema)
  })

export const FormSchema = z.object({
  email: z.string().email(),
  username: z.string().min(3, { message: "Must be more than 3 characters" }),
  pizzaChoice: z.string(),
  accept: z.literal(true, {
    errorMap: () => ({
      message: "You must accept Terms and Conditions."
    })
  }),
  tier: z
    .string({ invalid_type_error: "Please select a payment tier." })
    .refine((val) => Tiers.map((tier) => tier.id).includes(val))
})

<Form schema={FormSchema} onSubmit={onSubmit} defaultValues={someInitialValues}>
...
</Form>

Live example with Typescript validation

I have a live example with valid Typescript and the name attributes needs to be one of the keys of the schema.

You can find the live example here

How to clean up git branches in a sweep

Patrice Gauthier — Wed, 22 Jul 2020 13:58:52 +0000

You have been working a while and have created a lot branches. They are piling up. You forgot about them but they impede your productivity.
You want to push your branch but the autocomplete in terminal is stopping at the last character because it can't guess which branch you mean.

You have too much branches locally.

I have a simple trick to that allows you to delete many branches at once while selecting which one using the NPM project ipt

First install it by doing

npm i -g ipt

Now in the repo you want to delete branches do:

git branches|ipt -m|xargs -I{} git branch -d {}

or -D {} to force delete.

The above first list all the branches piping the list to ipt (with the select multiple option) then a list of the selected will be piped to xargs that will do a git branch -d <branch> which will delete each branch 🎉

Bonus: Using the git extension of ohmyzsh

gb|ipt -m|xargs -I{} git branch -d {}

sadly using aliases (gb) doesn't work with xargs.

Thats'all!