Click on the video above to watch.

The FBI handgun qualification is a well known standard demonstration of handgun proficiency. This longstanding course of fire was updated in 2019 and includes some new challenges which will push yours skills!

The 50-round course of fire covers distances from 3 to 25 yards and includes single hand shooting, off hand shooting, holster work, standing and kneeling positions.

There are two levels of qualifications: 80/100 for standard qualification and 90/100 for instructor level.

The 10 strings of fire offer some very challenging time limits. Lets see if you have what it takes to measure up against America’s G-Men.

Click HERE for the Course of Fire and Scoresheet

This challenge is courtesy of our non-profit FASTER Saves Lives program, which trains school employees how to protect our children.

How FASTER Challenges Work:

Each month we will issue a new challenge to help you practice self defense skills. Just for TRYING the challenge you will receive a custom FASTER Challenge patch to commemorate your effort and support.

The patch is a standard embroidered Velcro-backed 2″ x 3″ patch suitable for putting on hats, jackets, book-bags, range bags, and anywhere else Velcro will stick.

So get out, take the challenge, support FASTER, and have some fun!

1) Go to FASTERSavesLives.org and scroll to the bottom of the page where you will see the heading “Upcoming FASTER Training.” Click that link to begin registration for each challenge.

2) You will see a link that lets you download the course of fire.

3) The "Join the Challenge Now" button is where you actually sign up for the challenge. The cost monthly will be $20 for the challenge patch and for the official targets if you need them. Join the challenge now, because once the month is over, if you still want to take the challenge you can, but the price goes up on the first of the following month.

4) Go to the range or an appropriate space of land, use top-notch gun safety, and take the challenge! Make sure you learn and have fun while you do it! There is no required score. And it’s on the honor system.

5) Please take pics and tag us on our social media accounts and help us spread the word and fund the mission of FASTER Saves Lives! #FASTERChallenge
Facebook: @FASTERSavesLives
Twitter: @FASTERSaves
Instagram: @FASTERSavesLives

6) When your patch arrives in 2-4 weeks, wear it proudly and get others to take the challenges with you.

7) Sign up for the next challenge. We plan on offering a different challenge each month.

If you have questions, contact the Challenge Program leader:
Tom Hall
Tom@FASTERSavesLives.org
740-550-4159

Twenty years ago today, Joel Spolsky (who later co-founded Stack Overflow) published The Joel Test: 12 Steps to Better Code listing 12 metrics for rating the quality of a software development team. The premise is simple: you get 1 point for each “yes” answer, for a total score of up to 12 points.

It’s presented a bit tongue-in-cheek: he freely acknowledges it as “sloppy” and even “highly irresponsible”. But the list resonated with so many software developers that it’s still commonly in use today. Many job posts still include their “Joel Score” as a signal to developers that they care about the health and quality of their team.

Here at Tighten, we regularly discuss (and publish) our opinions about what makes a good software team, and how to maximize our own team’s health, productivity, and happiness. So we thought it would be fun to celebrate the 20 year anniversary of this iconic post with our own twist on it—heavily opinionated, based on our shared values, and sourced from our experience as web and app developers who regularly work with a variety of different software organizations.

The Tighten Test

1. Do you work 40 hours a week or less?
2. Do you set aside time at work for learning?
3. Do you have the tools you need to get the job done?
4. Do you keep an up-to-date list of prioritized tasks/tickets?
5. When new features take longer than expected, do you cut their scope and/or extend the timeline?
6. Do your codebases have up-to-date written setup and deployment instructions?
7. Do you write great commit messages and pull requests?
8. Is all incoming code automatically linted and tested?
9. Is all incoming code reviewed by someone who didn’t write it (or written while pairing)?
10. Do your local and staging environments match production as closely as possible?
11. Are you automatically notified about errors in production?
12. Do you deploy to production at least once a week?

As with the original test, 12/12 is a perfect score, 11 is tolerable, but 10 or lower and you’ll start noticing problems. Joel also noted that most software organizations are running with a score of 2 or 3.

1. Do you work 40 hours a week or less?

This one should be self-explanatory: the easiest way to ensure people are happy is to give them time to enjoy their life and maintain their health. There are many studies about the negative effects on health caused by overworking, and employees who are healthy tend to be happier and more productive. Some companies like Microsoft have even been experimenting with four-day workweeks in recent years—and seeing boosts in productivity.

At Tighten we don’t have a four-day workweek (yet? 😉), but we’ve been taking 20% time on Fridays since 2016: more on this in the next section. We also don’t work overtime.

2. Do you set aside time at work for learning?

It’s one thing to be a good developer, but to stay a good developer you have to constantly learn new things and also keep your existing skills sharp. While it’s impossible to learn everything, the best software development teams make some space for learning at work.

As mentioned, at Tighten we dedicate a day every week to learning and teaching: on Fridays we contribute to open source, read or watch tutorials, write blog posts, etc., instead of our usual client work. But you don’t need to set aside an entire day—there are other ways to make space for learning, like encouraging pair programming to spread knowledge around, including time for research in your tasks, and arranging internal talks within your team.

3. Do you have the tools you need to get the job done?

If someone on your team needs a license for something, can they get it? If you need specific office equipment—like an ergonomic desk or keyboard—will your company provide it for you?

Some developers manage to produce amazing work on old, slow laptops—or even a paper and pencil—but if your company’s business depends on your software, everyone on your team needs hardware that won’t slow them down, software to make them more productive, an office setup that maximizes their physical well-being, and space to take care of their mental health.

4. Do you keep an up-to-date list of prioritized tasks/tickets?

Joel’s original test included “Do you have a bug database?”, but we wanted to stress the importance of regularly prioritizing tickets at the top of your list. Working on the right thing is more important than doing good work on the wrong thing, so make sure your team is regularly re-ordering tickets so developers are always picking up the highest priority task.

5. When new features take longer than expected, do you cut their scope and/or extend the timeline?

In our experience, setting deadlines based on estimates doesn’t work, since estimates are merely a guess at what might happen in the future; not only is software complex and unpredictable, but requirements and priorities change all the time. Deadlines also tend to be the primary cause of overtime; many teams “crunch” to hit a due date, which can jeopardize team members’ physical & mental health.

Instead of estimating and pretending to know the future, we just do our best work every day and keep in close communication with our clients so everyone always knows the status of the project. If a client has a target to hit, we work with them to cut the scope of the requested feature—fans of agile practices will be familiar with this tactic—to ensure a usable, simpler version of what they need will be done with time to spare. If there’s time left later, you can always go back and add more to a feature.

Cutting scope allows us ship to production early and often, get feedback on features from real users faster, and save a lot of time by not developing and maintaining complex additions when users end up needing something different than expected.

6. Do your codebases have up-to-date written setup and deployment instructions?

How long does it take a new developer to get set up with your codebase? Without written instructions, it might take anywhere from a few days to a few weeks.

Since we work with a variety of clients, we’re constantly the new developers on a project—and while not having written instructions doesn’t necessarily mean your code is bad, we find that well-documented codebases are a good indication of regular maintenance and care for the project. Written instructions also help your team internally: for example, they can make a huge difference if the only person who knows how to deploy leaves the company.

7. Do you write great commit messages and pull requests?

While Git history might not be as important on solo projects, it matters a lot on a team. As frequent newcomers to a project, commit messages are invaluable in helping us understand why changes were made and how they relate to each other, without needing years of context or domain knowledge.

Understanding existing code is often the most time-consuming part of a development task. Once someone on a team wraps their brain around a programming challenge, it would be silly to have other developers spend that time again when they review or change the same code—but that’s exactly what happens when you leave commit messages and PR descriptions blank. The moment you submit a PR, you have more context about the task you’re working on than anyone else, so write it down while you remember! This will save time for everyone else: people who review your PR, new developers in the future who dig through Git history, and even future you when you can’t remember the details.

Great pull requests should also be digestible: ideally containing visual demonstrations, and small enough to be reviewable in 30 minutes or less. Since PR reviewers don’t have as much context as the developer who worked on a task, reviewing a huge PR can be disproportionately time-consuming.

8. Is all incoming code automatically linted and tested?

Disagreements about code style happen on every development team, but that’s no reason to let them get in the way of getting work done. Pick a style (preferably the standard in whatever language you’re using) and use linter and/or fixer tools to enforce it automatically, and never waste time arguing about code style again. You can fix your entire codebase in one go and ignore the commit in Git blame to maintain a useful history. As an added benefit, all future code changes will be easier to review since your diffs won’t be cluttered with meaningless changes to code style.

Running automated tests against all new code is also essential. Existing tests make sure new code hasn’t broken anything, and new tests protect new code from breaking in the future. The amount of code covered by tests matters too: most of it should be covered (though 100% coverage is often more trouble than it’s worth). Running an automated test suite with one test is better than nothing, but ultimately not enough to give you confidence that your app still works.

9. Is all incoming code reviewed by someone who didn’t write it (or written while pairing)?

One way we ensure that our code is of the highest quality possible is by always having a fresh set of eyes look it over before we consider it “done”.

Whenever possible we work in two-person teams, with each developer reviewing the other’s PRs on GitHub before they’re merged. We also have a strong pair programming culture here, where two developers will work together on the same code simultaneously while sharing screens over Zoom or some other tool.

Particularly when building large or complex features, pair programming often results in superior code compared to code that was written solo—not only because it helps weed out errors before they make it into a commit, but also because pairing allows the developers to reason through design decisions together in real-time, in a deeper and more meaningful way than is possible during a conventional code review. Plus, pairing can be a ton of fun, and is a great way to learn from one another!

Either way, whether through pairing or a GitHub-based code review of a PR—when it comes to code quality, four eyes are always better than two.

10. Do your local and staging environments match production as closely as possible?

Developing on different framework, language, database, or operating system versions will almost certainly cause unnecessary friction (“It works on my machine!”). Limiting the differences between environments also limits time wasted on errors caused by mismatched software versions. If you use build scripts and dependency managers (like Composer), you can update dependencies automatically in all environments, and take advantage of new language or software features everywhere.

Using tools like Docker, you can go even further and have your environments match exactly. If your local, staging, and production environments are identical, developers can prepare the application for the exact environment in which it will run. And with continuous integration and deployment (CI/CD), updates to the project and environment can be built, tested, and shipped the same way.

11. Are you automatically notified about errors in production?

Nobody writes bug-free code, and you can’t fix errors you don’t know about. Make sure any errors that occur in production are reported somewhere the whole team can see. Many legacy PHP apps silence errors altogether, which is even worse—silencing an error doesn’t make it go away! There are plenty of bug reporting services like Bugsnag and Sentry that give you a full stack trace, request & session data, and all the context you’ll need to fix most errors, as well as configurable notification channels like Slack.

12. Do you deploy to production at least once a week?

The timeframe is arbitrary; the important thing here is that you’re deploying to production frequently. Deploying shouldn’t be a big, scary event: if you do it often enough, if your deployments happen automatically after tests pass, and if you report errors in production there’s really not much to worry about. Modern continuous integration (CI) pipelines make it easier than ever to deploy automatically. We use tools like GitHub Actions and Laravel Envoyer to deploy to production every time we push code and our tests pass.

If you don’t meet all of these guidelines today, don’t worry! They simply serve as a set of goals our team has agreed to work toward, because they make us happier and more productive developers. We hope they’ll do the same for you.

Thanks to @dhicking for the original half-baked idea behind this post, and @jakebathman, @keithdamiani, and @marcusamoore for contributing content & reviewing.

We LOVE Costco! We love the product selections, we love the prices, we love the food court, we love the fuel discounts, we love car rental prices, and more. If you’ve don’t have a Costco Membership, this is the deal you’ve been waiting for.

Groupon is offering a Costco Membership Deal that you don’t want to miss!

For a limited time, you can purchase a One-Year Costco Gold Star Membership Package which includes a $40 Costco Shop Card and $40 Off Online Order for just $60! 

This offer is valid for NEW members, or for prior members whose memberships expired prior to April 1, 2020. This deal is not valid for membership renewals

Costco Membership Deal details

The deal includes a one-year Costco Gold Star membership for $60 (regular price), but includes a cash card and coupons that make it worth trying out the membership. Even if you only shop in-person at Costco and use the $40 gift card, you’ll only pay $20 for the membership.

• A One-Year Costco Gold Star Membership with auto-renewal of the Costco membership using a Visa® credit or debit card. It’s easy to cancel your Costco membership before or right after the renewal – they will prorate your refund at any time during your regularly priced membership.
• A membership card for the Primary Cardholder and one additional Household Card for anyone living at the same address, over the age of 18
• A $40 Costco shop card (gift card is valid towards any purchase, including gas). This is an amazing offer! 
• $40 off any order of $250+ on Costco.com

Why I love Costco

We have had a Costco membership for over 10 years – even when we were just a 2-person family. Now that we have 2 children, the amount of money we’ve saved on groceries, household goods, clothing, diapers, beverages, vacation car rentals, insurance, new tires, and more is WAY more than we’ve paid for our membership. 

Did I mention the clothing? I should be embarrassed by how much clothing I’ve purchased from Costco, but I’m not. The clothing rotates regularly, and they offer clothing and shoe brands such as Adidas, PUMA, Free People, Champion, Columbia, Eddie Bauer, Hunter (including Boots at times!), Tom’s, Buffalo, Lucky Brand, Nautica, and more. They also carry fine jewelry, designer bags, and more. I love that you can order the clothing online with free shipping, and return to the store if I don’t like it. 

Costco’s return policy is one of the best in the biz. They offer no-questions-asked returns for most items that they sell at any time (select electronics excluded).

Once you purchase the deal, you’ll have to go online to activate (it’s super easy).

Costco often has GREAT deals on holiday gifts for all ages, so now is the perfect time to join!

Other articles of interest

Laravel has a new Broadcaster: Larasocket. Today, we are going to see how we can use Larasocket with Tailwind, Alpine, and Livewire to build a beautiful, and lightweight real-time chat room. You can view the complete tutorial here.

What is the TALL stack?

Tailwind: Made by Adam Wathan. A powerful, lightweight, CSS library made up of utility classes. Utility classes offer all the power of normal CSS in a class-based interface for developers. Need to add margin-right? Just add the class mr-{amount}

Alpine: Made by Caleb Porzio. A lightweight javascript library for simple client-side logic without needing the bulky Vue or React frameworks.

Livewire: Made by Caleb Porzio. A powerful library to help the abstract client to server communication. Need to make an AJAX request to submit a form? Not anymore. Livewire offers an easy way to call PHP code, right from the clients, as well as re-render to UI based on backend changes.

Laravel: From laravel.com: “Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.”

Getting Started

We can quickly get started using a few helpful commands on the CLI:

laravel new larasocket-tall-demo
cd larasocket-tall-demo
composer require livewire/livewire laravel-frontend-presets/tall
php artisan ui tall --auth

For any Laravel application that uses Broadcasting, we need to uncomment this line in config/app.php :

// App\Providers\BroadcastServiceProvider::class,

Broadcasting with Larasocket

Now that our Laravel application is off the ground, let’s bring in Larasocket to use as our broadcaster. It’s free to get started 💪

composer require larasocket/larasocket-driver
npm i laravel-echo larasocket-js

Over in config/broadcasting.php we need to add the Larasocket driver as an option:

'larasocket' => [
    'driver' => 'larasocket',
    'token' => env('LARASOCKET_TOKEN'),
],

And let’s update bootstrap.js to use Larasocket instead of the default Pusher:

import Echo from 'laravel-echo';
import Larasocket from 'larasocket-js';

window.Echo = new Echo({
    broadcaster: Larasocket,
    token: process.env.MIX_LARASOCKET_TOKEN,
});

The last thing we need to do for Larasocket is to update our .env file:

BROADCAST_DRIVER=larasocket
LARASOCKET_TOKEN=<token>
MIX_LARASOCKET_TOKEN="${LARASOCKET_TOKEN}"

Just remember to replace <token> with your token from Larasocket. They are free!

Chat

Time for the fun part, building our chat room.

php artisan make:model Message -m
php artisan make:event MessageSentEvent
php artisan make:livewire ChatRoom

We can now update the newly createdcreate_messages_table migration with:

Schema::create('messages', function (Blueprint $table) {
    $table->id();
    $table->text('body');
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->timestamps();
});

We are all done making database changes so let’s persist these:

php artisan migrate

Let’s add our column and relationship to Message.php:

class Message extends Model
{
    protected $fillable = [
        'body'
    ];

    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

Over in User.php we can add the messages relationship:

public function messages()
{
    return $this->hasMany(Message::class);
}

Laravel Events provide a great interface to send data in the socket messages. Let’s update our newly created MessageSentEvent to pass along the needed data:

class MessageSentEvent implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;
/**
     * @var Message
     */
private $message;

/**
     * Create a new event instance.
     *
     * @return void
     */
public function __construct(Message $message)
    {
        $this->message = $message;
    }

/**
     * Get the channels the event should broadcast on.
     *
     * @return \Illuminate\Broadcasting\Channel|array
     */
public function broadcastOn()
    {
        return new PresenceChannel('demo');
    }

/**
     * JSON data to broadcast with this message
     */
public function broadcastWith()
    {
        return $this->message->toArray();
    }
}

Later on, we will dispatch this event when the user submits their message.

Important: don’t forget the implements ShouldBroadcast! This interface tells Laravel to use the Broadcaster to send out socket messages using whichever driver you have configured.

There is just one last task before our backend is ready. We need to secure the demo channel using routes/channels.php:

Broadcast::channel('demo', function ($user) {
    return [
        'id' => $user->id,
        'name' => $user->name,
    ];
});

Front-End

Remember that ChatRoom Livewire component we made earlier? It is now time to put it to work. The first thing we need to do is create a new route in our routes/web.php file:

Route::livewire('chat', 'chat-room')->middleware('auth')->layout('layouts.auth');

When you have a simple route and don’t need a method in a controller to return your view, you can use Route:view('path', 'myview') as a route.

Laravel Livewire comes with a nifty helper that is very similar: Route::livewire('path','mylivewireviewcomponent'). This is what we are using above.

Next, let’s build out the functionality:

class ChatRoom extends Component
{
    public $messages = [];
    public $here = [];

    protected $listeners = [
        'echo-presence:demo,here' => 'here',
        'echo-presence:demo,joining' => 'joining',
        'echo-presence:demo,leaving' => 'leaving',
    ];

    public function render()
    {
        return view('livewire.chat-room');
    }

    public function mount()
    {
        $this->messages = Message::
with('user')
            ->latest()
            ->limit(30)
            ->get()
            ->reverse()
            ->values()
            ->toArray();
    }

    public function sendMessage($body)
    {
        if (! $body) {
            $this->addError('messageBody', 'Message body is required.');
            return;
        }

        $message = Auth::user()->messages()->create([
            'body' => $body,
        ]);

        $message->load('user');

        broadcast(new MessageSentEvent($message))->toOthers();

array_push($this->messages, $message);
    }

/**
     * @param $message
     */
public function incomingMessage($message)
    {
// get the hydrated model from incoming json/array.
$message = Message::with('user')->find($message['id']);

array_push($this->messages, $message);
    }

/**
     * @param $data
     */
public function here($data)
    {
        $this->here = $data;
    }

/**
     * @param $data
     */
public function leaving($data)
    {
        $here = collect($this->here);

        $firstIndex = $here->search(function ($authData) use ($data) {
            return $authData['id'] == $data['id'];
        });

        $here->splice($firstIndex, 1);

        $this->here = $here->toArray();
    }

/**
     * @param $data
     */
public function joining($data)
    {
        $this->here[] = $data;
    }
}

Laravel Livewire is doing a lot behind the scenes for us.

First, note the protected $listeners array. Livewire uses this array to automatically subscribe to channels (uses Echo, in Javascript) for us. You can read more about that here. We will use the standard here, join, leaving presence channel events to keep track of who is in the chat room.

Currently, there is a Livewire bug that limits the presence channels we can subscribe to. It only allows those 3. Not a problem, we will leverage Alpine to easily subscribe to more channels in the Javascript. Let’s create the UI to go with our ChatRoom. In chat-room.blade.php let’s update it with:

@section('title', 'Larasocket Demo')

<div
    class="mt-4 bg-white rounded-lg shadow-md p-6"
    x-data=""
    x-init="
            Echo.join('demo')
                .listen('MessageSentEvent', (e) => {
                    @this.call('incomingMessage', e)
                })
            ">

    <div class="flex flex-row flex-wrap border-b">
        <div class="text-gray-600 w-full mb-4">Members:</div>

        @forelse($here as $authData)
            <div class="px-2 py-1 text-white bg-blue-700 rounded mr-4 mb-4">
                
            </div>
        @empty
            <div class="py-4 text-gray-600">
                It's quiet in here...
            </div>
        @endforelse
    </div>

    <template x-if="messages.length > 0">
        <template
            x-for="message in messages"
            :key="message.id"
        >
            <div class="my-8">
                <div class="flex flex-row justify-between border-b border-gray-200">
                    <span class="text-gray-600" x-text="message.user.name"></span>
                    <span class="text-gray-500 text-xs" x-text="message.created_at"></span>
                </div>
                <div class="my-4 text-gray-800" x-text="message.body"></div>
            </div>
        </template>
    </template>

    <template x-if="messages.length == 0">
        <div class="py-4 text-gray-600">
            It's quiet in here...
        </div>
    </template>

    <div
        class="flex flex-row justify-between"
    >
        <input
            @keydown.enter="
                @this.call('sendMessage', messageBody)
                messageBody = ''
            "
            x-model="messageBody"
            class="mr-4 shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
            type="text"
            placeholder="Hello World!">

        <button
            @click="
                @this.call('sendMessage', messageBody)
                messageBody = ''
            "
            class="btn btn-primary self-stretch"
        >
            Send
        </button>
    </div>
    @error('messageBody') <div class="error mt-2"></div> @enderror
</div>

Note that we are using Tailwind to help construct a pleasant UI, easily. Tailwind provides a nice library of CSS classes to easily update margin, padding, borders, display, colors, everything, and anything. Styling our elements in using Tailwind has a few key advantages:

1. Lightweight
2. Readable class names
3. Standardizes styling across organizations
4. Customizable
5. More

We are now ready to give our application using the Tailwind, AlpineJS, Livewire, and Laravel stack a go.

Let’s compile our front-end assets:

npm install
npm run dev

… and run our server:

php artisan serve

You can navigate to http://127.0.0.1:8000/chat and start playing with Larasocket and your chat room.

Related:

1. Building a real-time chat application with Laravel and Larasocket
2. Laravel Broadcasting in 2020
3. Larasocket: Laravel’s Newest Websocket Broadcasting Solution