If you have a Laravel application that schedules commands to run at specific times using the `app/Console/Kernel.php` file, you may want to add a test that ensures that the scheduled command is running correctly.

First, create a new test file in the tests directory of your Laravel application. In this example, we'll call the file KernelTest.php and the purpose is to test that the `inspire` command is scheduled to run every hour.

_Note: For the example I am using the phppest syntax but you should be able to adapt the code in case you use the built-in syntax:_

```php
use Illuminate\Console\Scheduling\Event;
use Illuminate\Console\Scheduling\Schedule;

it('schedules the `inspire` command correctly', function () {
    $schedule = app()->make(Schedule::class);

    $events = collect($schedule->events())->filter(function (Event $event) {
        return stripos($event->command, 'inspire');
    });

    if ($events->count() == 0) {
        $this->fail('No events found');
    }

    $events->each(function (Event $event) {
        $this->assertEquals('0 * * * *', $event->expression);
    });
});
```

In this test, we first get an instance of the Schedule class using the app function. We then use the events method to get an array of all scheduled events.

We then use the filter method to find any events that have the command property containing the word 'inspire'. If no events are found, we fail the test.

If one or more events are found, we use the each method to loop through each event and assert that the expression property is set to `'0 * * * *'`, which indicates that the command is scheduled to run every hour.

To run the test, use the following command:

```console
php artisan test --filter KernelTest
```

This test should pass if the inspire command is scheduled to run every hour in the Kernel class.

That's it! You now have a test to ensure that your scheduled commands are running correctly in your Laravel application.

Test that a laravel command is scheduled

MetaMask is a popular browser extension that allows users to interact with Ethereum-based applications. It is available for Chrome, Firefox, Brave, Edge, and Opera. In this post, we will explore how to detect if a user's browser is compatible with MetaMask.

One way to check for compatibility is to simply check if the `window.ethereum` object is present. This object is only defined in browsers that have MetaMask installed (including the metamask browser on mobile devices), so if it is present, we can assume that the browser is compatible.

```js
if (!!window.ethereum) {
	return true;
}
```

However, we may also want to check for compatibility even if MetaMask is not installed. In this case, we can check the user's browser type and exclude mobile browsers, as MetaMask is not currently available on mobile.

```js
const isCompatible = /chrome|firefox/.test(navigator.userAgent.toLowerCase());
const isMobile = /android|iphone|ipad|ipod/.test(navigator.userAgent.toLowerCase());

if (isCompatible && !isMobile) {
	return true;
}
```

Putting it all together, we can create a function that returns a boolean indicating whether the browser is compatible with MetaMask.

```js
function isMetaMaskSupportedBrowser() {
	// If the user has MetaMask installed, we can assume they are on a supported browser
	if (!!window.ethereum) {
		return true;
	}

	const isCompatible = /chrome|firefox/.test(navigator.userAgent.toLowerCase());
	const isMobile = /android|iphone|ipad|ipod/.test(navigator.userAgent.toLowerCase());

	return isCompatible && !isMobile;
}
```

This function can be useful for displaying a warning or error message to users who are on an unsupported browser, or for limiting the functionality of an application to only supported browsers.

Detect if Browser Supports MetaMask

Command line applications (CLIs) are a useful way to interact with your computer and perform tasks without a graphical interface. They are especially useful for automating tasks and writing scripts.

In this tutorial, we'll learn how to create a command line application in Rust that *hypothetically* reads a given file path and stores its contents in a database. To do this, we'll be using the [clap crate](https://docs.rs/clap/latest/clap/), clap is a command line argument parser that simplifies the process of parsing arguments and options passed to your CLI.

First, we'll need to add clap to our Cargo.toml file, to do that run the following command in your console: 

```console
cargo add clap --features derive
```

Alternatively you can manually add the dependency:

```toml
[dependencies]
clap = { version = "4.0.32", features = ["derive"] }
``` 

Next, create a new Rust file (`main.rs`) and add the following code:

```
use clap::Parser;

/// Read the input file and store the contents in a database
#[derive(Parser, Debug)]
#[command(author = "Alfonso Bribiesca", version, about, long_about = None)]
struct Args {
    /// File path to read
    input_file: String,

    /// Create a new table
    #[arg(short, long, default_value = "false")]
    create_table: bool,

    /// Drop the table
    #[arg(short, long, default_value = "false")]
    drop_table: bool,

    /// Table name
    #[arg(short, long="table", default_value = "")]
    table_name: String,
}

```

This code is for a CLI for reading an input file and storing its contents in a database.

It defines a struct called `Args` that represents the arguments and options passed to the CLI. The `#[derive(Parser, Debug)]` attribute generates code for parsing the command line arguments and options and for printing the values of the Args struct. The `#[command(author = "Alfonso Bribiesca", version, about, long_about = None)]` attribute provides metadata about the CLI, such as the author's name and a brief description of the CLI.

The `Args` struct contains four fields:

- `input_file`: a `String` representing the input file passed as the first argument to the CLI.
- `create_table`: a `bool` representing whether the create_table option is set. If this option is set, a new table will be hypothetically created in the database.
- `drop_table`: a `bool` representing whether the drop_table option is set. If this option is set, the table will be hypothetically dropped (deleted) from the database.
- `table_name`: a `String` representing the name of the table that hypothetically will be used to name the database table.

To define the arguments and options for our CLI, we use the `#[arg(short, long, value_name = "VALUE", index = INDEX, default_value = "DEFAULT")]` attribute. The `short` and `long` arguments define the short and long forms of the option, respectively. The `default_value` argument specifies a default value for the option if it is not provided. 

Now let's add the main function to our code:

```rust
fn main() {
    let args = Args::parse();

    // Print all args
    println!("{:#?}", args);
}
```

In the main function, we call the `Args::parse()` method to parse the command line arguments and options. This method returns an Args struct containing the values of the arguments and options passed to the CLI.

We can then print the values of the `Args` struct using the `println!` macro. This is useful for debugging and understanding the values passed to the CLI.

With this, you will have a basic CLI. Now it's up to you to add the actual functionality.

You can test the application by running the command:

```console
cargo run -- <arguments>
```

Replace `<arguments>` with the arguments and options you want to pass to the CLI. For example:

`cargo run -- --drop-table --table=my-table /path/to/file.xls`

It should return the following output:

```console
Args {
    input_file: "/ath/to/file.xls",
    create_table: false,
    drop_table: true,
    table_name: "my-table",
}
```

You can also use the `--help` option to see a list of available options and the summary of your application.

`cargo run -- --help`

```console
Read the input file and store the contents in a database

Usage: parser [OPTIONS] <INPUT_FILE>

Arguments:
  <INPUT_FILE>  First positional argument is the input file

Options:
  -c, --create-table        Create a new table
  -d, --drop-table          Drop the table
  -t, --table <TABLE_NAME>  Table name [default: ]
  -h, --help                Print help information
  -V, --version             Print version information
```

I hope this helps! Let me know if you have any questions.

Build a Command Line Application in Rust

I was sure of something when I decided to start this site: I would write all the content in English, even though 1. it is not my native language, 2. let's say that languages(​​in general) have never been my greatest strength, and English is no exception.

English is the most widely spoken language, and although I do not have the sources to prove it, I am sure that in the field of technology and software, the total percentage of people who speak English is even higher, added to the fact that one of my interests with this site is to reach and connect with people from all over the world.

![](https://alfonsobries.s3.amazonaws.com/blog/pKVjU2EZG2hdDT9JHP1uc84MBrH0gcKN9koSwWQZ.png)

If writing is a challenge, writing in another language tests your patience. You have to review the content many times to be sure that it is understood, and you can still make mistakes. In my case and maybe the case of others, those mistakes can become insecurities about my content’s quality and discourage me from continuing with this project.

Anyway…, something that worked for me to overcome my fear of speaking (or writing) in English was to realize that I shouldn’t feel wrong about not completely dominating a different language and that the best way to improve is to practice, make mistakes, and receive feedback. Under that premise, I decided to add a function to this site to allow my readers to give me that feedback, so I can fix the error and learn.

### How does this form work?

In the lower-left corner, I added an avatar based on the [Winnie the Pooh Reading](https://knowyourmeme.com/memes/winnie-the-pooh-reading) meme that seemed to represent the feeling you get when you don't understand something. It appears when you start scrolling the site since I take that as a sign that the user is reading the post.

![](https://alfonsobries.s3.amazonaws.com/blog/8CLlmBh1tgSgspKYTI04ambitbkYzuQkcWECqDJE.png)

![](https://alfonsobries.s3.amazonaws.com/blog/mAMez8z4Is0fT425KL5jsSgdCR3cUX8SJJtMtdfA.gif)

When you click, a small form appears so that you can quickly tell me about the error you noticed without leaving the page.

![](https://alfonsobries.s3.amazonaws.com/blog/3BTMpFqco3Oi75ATWTSeemyubSJcfpHEZHrFFP4k.gif)

The form can be temporarily hidden in case you want to copy and paste something or reread the text.

![](https://alfonsobries.s3.amazonaws.com/blog/7H9wfj5iXw7c84VvWnLbGp6QIcEWZHVpf1qSylfE.gif)

I used the telegram API so that when a new report is sent, I immediately receive a notification with a link to view or edit the post and thus resolve the problem as soon as possible.

![](https://alfonsobries.s3.amazonaws.com/blog/Q5EMOm8xKQ9vRRO578d9NGjwushOTuCokxvnXeni.png)


What do you think? You can use the “typo form” to give some comments.

Until the next blog update ✌️.

Blog Update: Added a way to report unclear articles or grammar errors

When using Vercel for monolithic projects that may contain files that are not part of the frontend, you may encounter a situation where every time you modify something that is not necessarily part of the frontend, Vercel triggers a new deployment that rebuilds the site automatically.

In those cases, you may need to ensure that the build process is only triggered when necessary.

Luckily Vercel has an [Ignored Build Step](https://vercel.com/docs/concepts/projects/overview#ignored-build-step) setting that allows you to disable the build step for specific scenarios, the problem is that the examples explain how you can trigger the build step in a particular folder but not how to ignore the folder. (For example, let's say that you don't want to build the entire site if you only changed the `/api` folder)

To do that, follow these steps:

1. Go to project settings:

![](https://api.alfonsobries.com/storage/DoaxRUowmHYORuYYPPHxA1QPNxNdVrzqMyf2SuRt.png)

2. Select the Git Tab:

![](https://api.alfonsobries.com/storage/zBzfT3bjk0JKDbn6YgSNKsMqwBonTEvQKotEs6DA.png)

3. Go to the Ignored Build Step

![](https://api.alfonsobries.com/storage/w1ZobWcgwRIpq7ScJbRChZQ0H3kEOnnBVcFBJMcG.png)

4. Add the following code:

```console
# Change `./api` for the path of the folder you want to ignore
git diff HEAD^ HEAD --quiet ':!./api'
```

![](https://api.alfonsobries.com/storage/bJ1DqeQrMQrbkARePI4pJi30LGFQ0ZXT1Mv4r0Q5.png)


You may also want to ignore certain file types. For those cases, modify the code as follows:

```console
# Replace `'php'` with the file extensions you want to ignore.
git diff HEAD^ HEAD --quiet ':!*.php'
```

You can also add multiple file types:

```console
git diff HEAD^ HEAD --quiet ':!*.php' ':!*.png'
```

Or a single file

```console
git diff HEAD^ HEAD --quiet ':!config.ts'
```

Posts / Page 2

Test that a laravel command is scheduled

Detect if Browser Supports MetaMask

Build a Command Line Application in Rust

Blog Update: Added a way to report unclear articles or grammar errors

How to ignore Vercel build step for certain folders and files