It would be crazy if I presented new Go features like this:

If you still don't use the synctest package, all your systems will eventually succumb to concurrency bugs.

or

If you don't use iterators, you have absolutely nothing interesting to build.

The job of an advocate is to spark interest, not to reproach people or instill FOMO. And yet that's exactly what AI advocates do.

What a weird way to advocate.

It's okay not to be early

This whole "devote your life to AI right now, or you'll be out of a job soon" narrative is false.

You don't have to be a world-class algorithm expert to write good software. You don't have to be a Linux expert to use containers. And you don't have to spend all your time now trying to become an expert in chasing ever-changing AI tech.

As with any new technology, developers adopting AI typically fall into four groups: early adopters, early majority, late majority, and laggards. Right now, AI advocates are trying to shame everyone into becoming early adopters. But it's perfectly okay to wait if you're sceptical. Being part of the late majority is a safe and reasonable choice. If anything, you'll have fewer bugs to deal with.

As the industry adopts AI practices, you'll naturally absorb just the right amount of them.

You are going to be fine.

Here is a little example of something that can be a nil pointer, but not a nil interface. Let’s walk through what that means.

Interfaces

First, go has a concept of interfaces, which are similar, but not quite the same as interfaces in some object-oriented languages (go is not OOP by most definitions). In go, an interface is a type that defines functions that another type must implement to satisfy the interface. This allows us to have multiple concrete types that can satisfy an interface in different ways.

For example, error is a built-in interface that has a single method. It looks like this:

1
2
3

type error interface {
    Error() string
}

Any type that wants to be used as an error must have a method called Error which returns a string. For example, the following code could be used:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type ErrorMessage string

func (em ErrorMessage) Error() string {
    return string(em)
}

func DoSomething() error {
    // Try to do something, and it fails.
    if somethingFailed {
        var err ErrorMessage = "This failed"
        return err
    }
    return nil
}

func main() {
    err := DoSomething()
    if err != nil {
        panic(err)
    }
}

Notice in this example that DoSomething returns an error if something goes wrong. We can use our ErrorMessage type, because it has the Error function, which returns a string, and therefore implements the error interface.If no error occurred, we returned nil.

Pointers

In go, pointers point to a value, but they can also point to no value, in which case the pointer is nil. For example:

1
2
3
4
5
6
7
8
9

var i *int = nil

func main() {
    if i == nil {
        j := 5
        i = &j
    }
    fmt.Println("i is", *i)
}

In this case, the i variable is a pointer to an int. It starts out as a nil pointer, until we create an int, and point it to that.

Pointers and interfaces

Since user-defined types can have functions (methods) attached, we can also have functions for pointers to types. This is a very common practice in go. This also means that pointers can also implement interfaces. In this way, we could have a value that is a non-nil interface, but still a nil pointer. Consider the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type TruthGetter interface {
    IsTrue() bool
}

func PrintIfTrue(tg TruthGetter) {
    if tg == nil {
        fmt.Println("I can't tell if it's true")
        return
    }
    if tg.IsTrue() {
        fmt.Println("It's true")
    } else {
        fmt.Println("It's not true")
    }
}

Any type that has an IsTrue() bool method can be passed to PrintIfTrue, but so can nil. So, we can do PrintIfTrue(nil) and it will print “I can’t tell if it’s true”.

We can also do something simple like this:

1
2
3
4
5
6
7
8
9
10

type Truthy bool

func (ty Truthy) IsTrue() bool {
    return bool(ty)
}

func main() {
    var ty Truthy = true
    PrintIfTrue(ty)
}

This will print “It’s true”.

Or, we can do something more complicated, like:

1
2
3
4
5
6
7
8
9
10

type TruthyNumber int

func (tn TruthyNumber) IsTrue() bool {
    return tn > 0
}

func main() {
    var tn TruthyNumber = -4
    PrintIfTrue(tn)
}

That will print “It’s not true”. Neither of these examples are pointers, and so there’s no chance for a nil with either of these types, but consider this:

1
2
3
4
5
6
7
8

type TruthyPerson struct {
    FirstName string
    LastName string
}

func (tp *TruthyPerson) IsTrue() bool {
    return tp.FirstName != "" && tp.LastName != ""
}

In this case TruthyPerson does not implement TruthGetter, but *TruthyPerson does. So, this should work:

1
2
3
4

func main() {
    tp := &TruthyPerson{"Jon", "Grady"}
    PrintIfTrue(tp)
}

This works because tp is a pointer to a TruthyPerson. However, if the pointer is nil, we’ll get a panic.

1
2
3
4

func main() {
    var tp *TruthyPerson
    PrintIfTrue(tp)
}

This will panic. However, the panic doesn’t happen in PrintIfTrue. You would think it’s fine, because PrintIfTrue checks for nil. But, here’s the issue. It’s checking nil against a TruthGetter. In other words, it’s checking for a nil interface, but not a nil pointer. And in func (tp *TruthyPerson) IsTrue() bool, we don’t check for a nil. In go, we can still call methods on a nil pointer, so the panic happens there. The fix is actually pretty easy.

1
2
3
4
5
6

func (tp *TruthyPerson) IsTrue() bool {
    if tp == nil {
        return false
    }
    return tp.FirstName != "" && tp.LastName != ""
}

Now, we’re checking for a nil interface in PrintIfTrue and for a nil pointer in func (tp *TruthyPerson) IsTrue() bool. And it will now print “It’s not true”. We can see all this code working here.

Bonus: Check for both nils at once with reflection

With reflection, we can make a small change to PrintIfTrue so that it can check for both nil interfaces and nil pointers. Here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

func PrintIfTrue(tg TruthGetter) {
if tg == nil {
fmt.Println("I can't tell if it's true")
return
}

val := reflect.ValueOf(tg)
k := val.Kind()
if (k == reflect.Pointer || k == reflect.Chan || k == reflect.Func || k == reflect.Map || k == reflect.Slice) && val.IsNil() {
fmt.Println("I can't tell if it's true")
return
}

if tg.IsTrue() {
fmt.Println("It's true")
} else {
fmt.Println("It's not true")
}
}

Here, we check for the nil interface first, as before. Next, we use reflection to get the type. chan, func, map, and slice can also be nil, in addition to pointers, so we check if the value is one of those types, and if so, check if it’s nil. And if it is, we also return the “I can’t tell if it’s true” message. This may or may not be exactly what you want, but it’s an option. With this change, we can do this:

1
2
3
4

func main() {
    var tp *TruthyPerson
    PrintIfTrue(tp)
}

You might sometimes see a suggestion to something simpler, like:

1
2
3
4
5

// Don't do this
if tg == nil && reflect.ValueOf(tg).IsNil() {
    fmt.Println("I can't tell if it's true")
    return
}

There are two reasons this doesn’t work well. First, is that there is a performance overhead when using reflection. If you can avoid using reflection, you probably should. If we check for the nil interface first, we don’t have to use reflection if it’s a nil interface.

The second reason is the reflect.Value.IsNil() will panic if the type of the value isn’t a type that can be nil. That’s why we add in the check for the kind. If we hadn’t checked the Kind, then we would’ve gotten a panic on the Truthy and TruthyNumber types.

So, as long as we ensure we check the kind first, this will now print “I can’t tell if it’s true”, instead of “It’s not true”. Depending on your perspective, this may be an improvement. Here is the complete code with this change.

Sometimes, strictly for testing purposes, we might need to access a private or protected property or method. Our usual inclination is to use Reflection to do this. Reflection is a bit cumbersome, though, because there’s a lot of extra boilerplate to set it up.

But closures actually provide us with a cool way to do that much more easily. If you’ve ever used JavaScript’s bind method, we can do the same thing in PHP.

Let’s start with a sample class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class Person
{
    public string $name = 'Dan';
    protected int $age  = 40;
    private bool $cool  = true;
    
    protected static string $species = 'homo sapien';
    
    protected static function evolve(): void
    {
        static::$species = 'homo superior';
    }
    
    protected function birthday(): void
    {
        $this->age++;
    }
    
    public function howOldAmI(): int
    {
        return $this->age;
    }
}

$me = new Person();

Non-static properties

We know how to read and change $me->name. It’s public, so there’s no problem there.

Now, what if we need, somewhere in a test, to set the exact age. That’s a protected property, so we can’t just directly change it, but Closures can give us a way around that.

1

(fn (int $newAge) => $this->age = $newAge)->call($me, 30); // Changes $me->age to 30

So, what did we do here? Let’s break it down a bit.

1

$changeAge = (fn (int $newAge) => $this->age = $newAge);

First, we create a closure that changes $this->age to whatever is passed to it. If we tried to do $changeAge(30), we’d get an error, though, because we defined this outside of the class. $this doesn’t actually exist here, or, if we put this code in a unit test, $this would refer to the unit test class itself.

That’s where call comes in. Closure::call binds a closure to a new object, and calls it with whatever args you passed to it. In other words, the first argument passed to call become the $this within the closure. Any other arguments are passed to the function itself.

1

$changeAge->call($me, 30);

We can also simply access the $age and $cool properties without changing them. So, I can do:

1
2

$amICool = (fn () => $this->cool)->call($me); // true
$myAge   = (fn () => $this->age)->call($me);

Static properties

That works great for the non-static properties or methods. What about the static ones?

1
2
3

$mySpecies = (fn () => static::$species)->bindTo(null, Person::class)(); // homo sapien
(fn () => static::evolve())->bindTo(null, Person::class)(); // Changes to homo superior
(fn (string $newSpecies) => static::$species = $newSpecies)->bindTo(null, Person::class)('homo erectus'); // devolve to homo erectus

So, this is a little different. First, we’re using Closure::bindTo which returns a new closure, which has been re-bound to the specified object or class. With bindTo, you can pass an object (like call), or you can leave that null and pass a class instead, which changes the static binding. That’s what we’ve done here. And since it returns a new closure, you then have to call it, which is why we have an extra () after.

So, let’s break this down step-by-step as well.

1

$getSpecies = (fn () => static::$species);

A closure which returns that $species of the current scope.

1

$boundGetSpecies = $getSpecies->bindTo(null, Person::class);

A new closure, which changes the scope to Person, meaning any references to static refer to Person.

1

$mySpecies = $boundGetSpecies();

Or, if we to change the species to an arbitrary value, as we did in the third one:

1
2
3
4
5
6

// Create species changing closure, initially bound to the current scope
$changeSpecies = (fn (string $newSpecies) => static::$species = $newSpecies);
// Create a new Closure, bound to the Person scope
$changePersonSpecies = $changeSpecies->bindTo(null, Person::class);
// Change it to whatever
$changePersonSpecies('homo erectus');

Using bindTo with an object

You can use bindTo in a similar way to call.

1

(fn () => $this->birthday())->bindTo($me)();

Let’s break it down.

1

$haveABirthday = (fn () => $this->birthday());

Closure which calls birthday() on the object within the current scope.

1

$haveMyBirthday = $haveABirthday->bindTo($me);

Create a new closure with $me as the scope. This way, any reference to $this refers to $me.

1

$haveMyBirthday();

Since $haveMyBirthday is a closure, we have to actually call it.

Conclusion

Sure, we can use ReflectionClass and ReflectionObject to do all of this, but this technique greatly simplifies it, since calling a single private method is a single line of code.

I actually use this in a package I recently wrote that should make this even easier.

And to reiterate, I do not recommend doing this in production code. There’s a reason visibility exists. We shouldn’t circumvent it like this in code on our server. But, if we need to fiddle around with some objects for testing, this technique can simplify that for us.

In spoken language, we see that many elements are universal, one being the way speakers listen and take turns in a conversation. These markers or thinking sounds (uh, uh huh, huh, hmm, er, like, right?) may be collections of sounds with meaningless lexical value, yet they pack a pragmatic punch.

They can be perceived with a range of filters, neutral or positive ones such as creating connection, agreement, and unity; or with a more negative view, such as a crutch, tic, parasitic word, or distracting habit. These exist in every language. The French utter eh bien; Portuguese have então, ta, pois; Japanese えーと (“eeto”), and なんか (“nanka”); Spanish – mira, vale, among others.

Understood by several labels, verbal fillers and hesitation markers are some of these universal elements, a type of discourse marker. Interjections and rejoinders also come to mind—words a listener uses to keep the conversation going and show the speaker she understands and even sympathizes with them; for language learners, using them adeptly (with the right syntactic placement, intonation, and timing) may demonstrate further fluency. […]

When the speaker is not visible, verbal “signposts,” can be helpful, as they take the role, in part, that nonverbals do. Politicians, public speakers, and those making a formal presentation, on the other hand, might gather their thoughts and hold the floor with a “Soooo…,” a “Look,” or an “Ummm” in between points. Learners of more than one language might hear these signals early on, and start incorporating them, purposefully or not, to create added fluency and confidence in the new target language.

Judgments of and reactions to these elements of speech range from perceiving a mark of personality—it’s simply what the speaker does—to a more visceral judgment (distracting, inept, unprofessional, unpracticed). Examples of these utterances include the well-known “you know” and “like,” and the increasingly more frequent “right?”

You know creates an exchange structure focusing the listener’s attention on a specific piece of information provided by the speaker. That seems like a lot to pay for a coffee, you know?

Like is a big one for protecting oneself from potential disagreement: “Do you, like, want to have Indian food for lunch?” perhaps really means: “Will you have Indian food for lunch with me?,” or functions to reduce uncertainty and perhaps avoid rebuttal or being wrong in an utterance:

It’s, like, supposed to rain all afternoon.

Right: Has this one crept in quickly or slowly? The peppering of a “right(?)” in the telling of a story or sharing new information can take the place of “Do you know what I mean?” Additionally, depending on placement and tone, it can connote a spoken yet implied request that the listener agree, while the listener might be thinking, “Must I agree? (I don’t, actually: I just learned this; this is his story; or I don’t agree at all.”) […]

Imagine how challenging it is to use verbal fillers accurately in a second or third language. Or, um, rather, since there is already a more spacious canvas, maybe one should not even bother sprinkling them in. Indeed, interpreters are trained to omit fillers, so as not to be perceived as uncertain or create doubt with the accuracy of an interpretation. Ironically, using filled pauses naturally, “accurately,” where they are expected in conversation, can result in the speaker being perceived as fluent, or at least communicatively competent in a second or third language. […]

Mark Liberman discovered, though his parsing of 14,000 phone conversations, that “uh” increases with age, but that at every age, male speakers use it more than female speakers do; whereas, “um” decreases with age, but female speakers use it more than male ones do at each stage in life.

The state of affairs is actually simple and one of a common ground: we each have our own idiolect, a term coined by Bernard Bloch from the Greek idio- (personal, distinct) + -lect (social variety of a language), which is the unique speech of an individual. This term refers to the theory that, while being influenced by or sharing a common dialect, sociolect, culture, and environment, no two individuals have the exact same linguistic tastes and idiosyncratic features in their personal inventory of variants.

Obligatory gripe: I’m tired of the ubiquitous “right?” and wish it would go away. Thanks, Martin!

If you’ve called add_action or add_filter, you’ve used a Wordpress hook. Ifyou’ve called do_action or appy_filters, you’ve created your own hook.

If you’ve spent some time working with Wordpress, and are now working withLaravel, you might be wondering if Laravel has a hook system as well. You’re inluck, using Laravel’s event system, you can do the same sort of thingsthat Wordpress’s hook system can do, and we’re going go over how to do that witha few code samples.

First off, lets talk about hooks in Wordpress.

Wordpress hooks

In Wordpress, hooks are a system that allow the developer to hook into anevent, and add some functionality. Hooks come in two varieties: actions, andfilters. Both types do essentially the same thing: when something happens in thesystem (or is about to happen), the action/filter is called. A developerbuilding a plugin or theme can add functions that run on these events.

The difference between these two types of hooks have to do with the data ispassed to the function, and the data that is returned from the function.

An action, is a function that returns nothing. In fact, if you add an actionthat returns a value, that value is ignored, and nothing happens with it.

A common example of an action is the built-in init action. This action is runearly on in the request lifecycle. One possible use is by theme developers whenregistering custom post types.

This might look like this:

1
2
3

add_action( 'init', function () {
    register_post_type( 'book', [ 'public' => true ] );
} );

A filter is a function that returns a value that is intended to modify whatevervalue is passed to it.

A good example of a filter is the body_class filter. The function is passed anarray of classes that are to be used in the <body class> attribute. Thefilter function should add to, or remove classes in the array, and then returnthe array.

This might look like this:

1
2
3
4
5

add_filter( 'body_class', function ( array $classes ) {
    $classes[] = 'i-love-hooks';
    
    return $classes;
} );

Now that we’ve got a refresher on Wordpress hooks, let’s look at Laravel Events.

Laravel Events

In Laravel, Events serve the same purpose as Wordpress hooks: whensomething happens, an event is triggered, and the developer can respond to thatevent by performing some action. One important difference to remember betweenWordpress hooks and Laravel Events are that in Wordpress, a hook has a name, andthat’s how you add your function to that hook, is by using the name. In Laravel,an event is an actual object which is instantiated. When you listen for thatevent (i.e., when you hook into it), you listen for events of a particularclassname. In this way, Laravel is using more object-oriented programming.

Laravel has a number of built-in events, and any developer can create their owncustom events. Let’s look at how one might be used.

One event provided by Laravel is the QueryExecuted event. This event isexecuted whenever a database query is made. The event contains the query, andthe amount of time (in milliseconds) that the query took to execute.

In Wordpress, you would add your hook listener during you plugin init function,or in your theme’s functions.php file, usually. In Laravel, normally, youregister an event listener in a service provider. You can use any serviceprovider, by adding the following to the boot method:

1
2
3
4
5
6
7

use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\Event;
use App\Listeners\LogQueries;

public function boot() {
    Event::listen(QueryExecuted::class, LogQueries::class);
}

In this example, LogQueries is a listener class that contains a method calledeither handle or __invoke. This method will get an instance of theQueryExecuted class. It might look something like this:

1
2
3
4
5
6
7
8

use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\Log;

class LogQueries {
    public function handle(QueryExecuted $evt) {
        Log::debug("Executed {$evt->sql} in {$evt->time}ms");
    }
}

You can also listen using a Closure, similar to the Wordpress examples I gavebefore. Something like this could be done in the service provider:

1
2
3
4
5
6
7
8
9

use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\Facades\Log;

public function boot() {
    Event::listen(function (QueryExecuted $evt) {
        Log::debug("Executed {$evt->sql} in {$evt->time}ms");
    });
}

There are other variations on how to do this. We won’t be going into detail inthese. Feel free to consult the official documentation.

Real-life (sort of) examples

For our examples, we’re going to imagine we’re building an e-book store usingLaravel. So, first, lets establish a few models that we’ll be using.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

namespace App\Models;

class Customer {
    // ...
}

class Book {
    // ...
}

class Checkout {
    public function customer(): HasOne
    {
        return $this->hasOne(Customer::class);
    }
    
    public function books(): BelongsToMany
    {
        return $this->belongsToMany(Book::class);
    }
}

We have customers, books, and for when they are making a purchase, checkouts.The checkout has a relationship to the customer and the books in the cart.

Actions

As we discussed earlier, Wordpress has two types of hooks: actions and filters.It should be clear by now how to use Laravel Events in the same way as Wordpressactions. But, lets go over this using our store example.

Let’s suppose our customer has already picked out their books, and added it tothe cart. We have our Checkout model ready, called $checkout, and thecustomer has just pressed the “Check out” button on the site. We go through somelogic to verify payment and shipping and whatnot, and everything’s fine, so oncethat’s all done, we can fire an event to indicate that checkout has completed.

We create this event with the command:

1

php artisan make:even CheckoutComplete

Our event class might look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class CheckoutComplete
{
    use Dispatchable, SerializesModels;

    public Checkout $checkout;

    public function __construct(Checkout $checkout)
    {
        $this->checkout = $checkout;
    }
}

And then, we’d dispatch it like this:

1
2
3
4

use Illuminate\Support\Facades\Event;
use App\Events\CheckoutComplete;

Event::dispatch(new CheckoutComplete($checkout));

All of this might be similar, in Wordpress to the following:

1

do_action( 'checkout_complete', $checkout );

Obviously the Wordpress code is much shorter, but the Laravel code gives us moretype-safety, and some more flexibility, since we can easily add whatever we wantto that event model.

Listening for the event

All we’ve done so far is create an event and dispatch it. Now we hook into it byusing a listener.

Let’s suppose whenever a customer makes a purchase, they get one reward point forevery book they purchased, and the points are redeemable for discounts in thefuture.

So, we use our CheckoutComplete event and create a listener that awards thesepoints.

So, our listener can be as simple as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

use App\Events\CheckoutComplete;
use App\Service\RewardPoints;

class GiveRewardPoints
{
    protected RewardPoints $service;

    public function __construct(RewardPoints $rewardsService)
    {
        $this->service = $rewardsService;
    }

    public function handle(CheckoutComplete $checkout)
    {
        $service->award($checkout->customer, $checkout->books()->count());
    }
}

We register this listener, as we explained above, in a service provider like:

1

Event::listen(CheckoutComplete::class, GiveRewardPoints::class);

You can register as many listeners for an event as you like.

All of this might be something like the following in Wordpress.

1
2
3
4
5

function give_reward_points( array $checkout ) {
    $rewardsService->award( $checkout['customer_id'], count( $checkout['books'] ) );
}

add_action( 'checkout_complete', 'give_reward_points' );

Filters

Actions are easy, but filters are a little less obvious. To understand how wecan use events like Wordpress filters, we need to note that since an event is anobject with values on it, we can modify those values on the event. This gives usmuch more flexibility than Wordpress filters, which only give us the option ofreturning a new value.

For our example, let’s suppose our customer has just entered their addressinformation during checkout. We might need to do some validation on thataddress. Normally in Laravel, you would probably throw a ValidationExceptionin this sort of case, but let’s try something a little different.

First, we’ll create a CheckoutAddressEntered event:

1
2
3
4
5
6

class CheckoutAddressEntered
{
    public Checkout $checkout;
    public Address $address;
    public array $errors = [];
}

We’ll suppose that the $address object is some sort of data transfer objectthat just holds the address information. The implementation isn’t important forour example.

Now, in our controller, we might have some logic like this:

1
2
3
4
5
6
7
8
9
10
11

$addressEntered = new CheckoutAddressEntered();
$addressEntered->checkout = $checkout;
$addressEntered->address = $address;

Event::dispatch($addressEntered);

if (count($addressEntered->errors)) {
    return new JsonResponse(['errors' => $addressEntered->errors]);
}

return new JsonResponse(['data' => $checkout]);

So, what did we do here exactly? We don’t have any errors on $addressEnteredhere. Let’s check out our listener.

1
2
3
4
5
6
7
8
9
10
11

class ValidateAddress
{
    public function __construct(protected AddressValidator $validator) { /**/ }
    
    public function handle(CheckoutAddressEntered $evt)
    {
        if (!$validator->validate($evt->address)) {
            $evt->errors[] = 'Address validation failed';
        }
    }
}

So, in our listener, we validated the address, and if it failed, we appended tothe errors array with a failure message. When we called Event::dispatch, ourlisteners were run with the same $addressEntered object being passed to thelistener. Each non-queued listener is run before Event::dispatch finishes, so,any changes made to the event are carried over.

If we were to implement this in Wordpress, it might look like this:

1
2
3
4
5
6

$errors = apply_filters( 'checkout_address_entered', [], $address, $checkout );
if ( count( $errors ) ) {
    wp_send_json_error( $errors, 400 );
} else {
    wp_send_json_success( $checkout );
}

And then, our callback would be:

1
2
3
4
5
6
7

function validate_address( array $errors, array $address, array $checkout ) {
    if ( ! $addressValidator->validate( $address ) ) {
        $errors[] = 'Address validation failed';
    }
}

add_filter( 'checkout_address_entered', 'validate_address', 10, 3 );

We might have another listener that checks that all of the books purchased canbe legally sold in the customer’s country.

One very important thing to note is that for this to work properly, thelistener cannot be a queued listener. If it is, thevalidation will happen outside of the request, after the response has alreadybeen sent to the client. If you used the make:listener artisan command tocreate the listener class, you’ll need to remove the ShouldQueue trait fromthat class.

Conclusion

If you’re coming from Wordpress to Laravel, there are a lot of new things tolearn. With hooks being such an integral part of Wordpress, hopefully learninghow Laravel events work will help make that transition.

But every time I decide to switch jobs, my first question about a potential new job is about what sort of health insurance benefits are provided.

And even when they do provide good insurance, I always have to ask a bunch of questions about availability and so on to ensure that I won’t go without coverage during the period that I’m switching from one job to another.

The fact that this is such a top concern when trying to decide where I’m going to work is absurd.

I don’t really understand the history of healthcare in the United States, so I just don’t understand how we came to be in a place where adequate healthcare become tied to employment.

And I really don’t understand the people that think that this is a reasonable way to do this. Why can’t we fix this, and just provide affordable healthcare to everybody? Why aren’t people willing to pay a little more in taxes so that nobody has to worry about whether or not they can afford to go to the doctor or get the medicines they need?

I just don’t get it.

App Platform is a hosting product, no surprise there, but it has some features that are Jamstack-inspired in the best possible way, and an additional set of unique and powerful features. Let’s start with some basics:

• Static sites can be hosted on the free tier
• Automatic HTTPS
• Global CDN (Cloudflare is in front, so you’re DDoS safe)
• Deploy from Git

That’s the stuff that developers like me are loving these days. Take some of the hardest, toil-laden, no-fun aspects of web development and entirely do them for me.

And now the drumroll:

• This isn’t just for static sites: it’s for PHP, Node, Python, Ruby, Go, Docker Containers, etc.
• You don’t have to configure and update things, these are boxes ready-to-go for those technologies.
• You can scale to whatever you need.
• You don’t pay by the team seat. Unlimited team members. You pay by usage like bandwidth and build time.

It extremely easy to deploy a static site

You snag it right from GitHub (or GitLab, or Docker Hub), which is great right away, and off you go.

Then we get our first little hint of something compelling right away:

But let’s say we don’t need that immediately, we can go with a free plan and get this out.

The site will build and you can see logs:

And lookie that my static site is LIVE!

Say my site needs to run an actual build process? That, and lots more configuration come in the form of an “App Spec”. This is where I would include those build commands, change Git information, deployment zones, and loads more.

About that database…

Wasn’t that interesting to see the setup steps for this static site suggest adding a database? So many sites need some kind of data store, and it’s often left up to developers to go find some kind of cloud-accessible data storage that will work well with their app. With Digital Ocean App Platform, it can live right alongside your static app.

It’s called a component.

As you can see, it can be, but doesn’t have to be a Database. It could be another type of server! Here I could pop a PostgreSQL DB on there for just $7/month.

If what you need to add is an internal or external service, it will let you add that via another Git repo that you hook up. Oh my what a modern system you now have. A front end and a back end each individually deployable directly via Git itself.

This is for server-side apps as well.

This feels big to me! I get that same kinda easy DX feeling I get with static sites, but with, say, a Python or Ruby on Rails app. Free deployment! Server boxes I don’t have to configure and manage myself!

Seems like a pretty happy-path hosting environment for lots of stuff.

The post App Platform on Digital Ocean appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

The Media Session API makes this possible. It gives media playback access to the user outside of the browser tab where it is playing. If implemented, it will be available in various places on the device, including:

• the notifications area on many mobile devices,
• on other wearables, and
• the media hub area of many desktop devices.

In addition, the Media Session API allows us to control media playback with media keys and voice assistants like Siri, Google Assistant, Bixby, or Alexa.

The Media Session API

The Media Session API mainly consists of the two following interfaces:

• MediaMetadata
• MediaSession

The MediaMetadata interface is what provides data about the playing media. It is responsible for letting us know the media’s title, album, artwork and artist (which is Kendrick Lamar in this example). The MediaSession interface is what is responsible for the media playback functionality.

Before we take a deep dive into the topic, we would have to take note of feature detection. It is good practice to check if a browser supports a feature before implementing it. To check if a browser supports the Media Session API, we would have to include the following in our JavaScript file:

if ('mediaSession' in navigator) {
  // Our media session api that lets us seek to the beginning of Kendrick Lamar's "Alright"
}

The MediaMetadata interface

The constructor, MediaMetadata.MediaMetadata() creates a new MediaMetadata object. After creating it, we can add the following properties:

• MediaMetadata.title sets or gets the title of the media playing.
• MediaMetadata.artist sets or gets the name of the artist or group of the media playing.
• MediaMetadata.album sets or gets the name of the album containing the media playing.
• MediaMetadata.artwork sets or gets the array of images related with the media playing.

The value of the artwork property of the MediaMetadata object is an array of MediaImage objects. A MediaImage object contains details describing an image associated with the media. The objects have the three following properties:

• src: the URL of the image
• sizes: indicates the size of the image so one image does not have to be scaled
• type: the MIME type of the image

Let’s create a MediaMetadata object for Kendrick Lamar’s “Alright” off his To Pimp a Butterfly album.

if ('mediaSession' in navigator) {
  navigator.mediaSession.metadata = new MediaMetadata({
    title: 'Alright',
    artist: 'Kendrick Lamar',
    album: 'To Pimp A Butterfly',
    artwork: [
      { src: 'https://mytechnicalarticle/kendrick-lamar/to-pimp-a-butterfly/alright/96x96', sizes: '96x96', type: 'image/png' },
      { src: 'https://mytechnicalarticle/kendrick-lamar/to-pimp-a-butterfly/alright/128x128', sizes: '128x128', type: 'image/png' },
      // More sizes, like 192x192, 256x256, 384x384, and 512x512
    ]
  });
}

The MediaSession interface

As stated earlier, this is what lets the user control the playback of the media. We can perform the following actions on the playing media through this interface:

• play: play the media
• pause: pause the media
• previoustrack: switch to the previous track
• nexttrack: switch to the next track
• seekbackward: seek backward from the current position, by a few seconds
• seekforward: seek forward from the current position, by a few seconds
• seekto: seek to a specified time from the current position
• stop: stop media playback
• skipad: skip past the advertisement playing, if any

The MediaSessionAction enumerated type makes these actions available as string types. To support any of these actions, we have to use the MediaSession’s setActionHandler() method to define a handler for that action. The method takes the action, and a callback that is called when the user invokes the action. Let us take a not-too-deep dive to understand it better.

To set handlers for the play and pause actions, we include the following in our JavaScript file:

let alright = new HTMLAudioElement();

if ('mediaSession' in navigator) {
  navigator.mediaSession.setActionHandler('play', () => {
    alright.play();
  });
  navigator.mediaSession.setActionHandler('pause', () => {
    alright.pause();
  });
}

Here we set the track to play when the user plays it and pause when the user pauses it through the media interface.

For the previoustrack and nexttrack actions, we include the following:

let u = new HTMLAudioElement();
let forSaleInterlude = new HTMLAudioElement();

if ('mediaSession' in navigator) {
  navigator.mediaSession.setActionHandler('previoustrack', () => {
    u.play();
  });
  navigator.mediaSession.setActionHandler('nexttrack', () => {
    forSaleInterlude.play();
  });
}

This might not completely be self-explanatory if you are not much of a Kendrick Lamar fan but hopefully, you get the gist. When the user wants to play the previous track, we set the previous track to play. When it is the next track, it is the next track.

To implement the seekbackward and seekforward actions, we include the following:

if ('mediaSession' in navigator) {
  navigator.mediaSession.setActionHandler('seekbackward', (details) => {
    alright.currentTime = alright.currentTime - (details.seekOffset || 10);
  });
  navigator.mediaSession.setActionHandler('seekforward', (details) => {
    alright.currentTime = alright.currentTime + (details.seekOffset || 10);
  });
}

Given that I don’t consider any of this self-explanatory, I would like to give a concise explanation about the seekbackward and seekforward actions. The handlers for both actions, seekbackward and seekforward, are fired, as their names imply, when the user wants to seek backward or forward by a few number of seconds. The MediaSessionActionDetails dictionary provides us the “few number of seconds” in a property, seekOffset. However, the seekOffset property is not always present because not all user agents act the same way. When it is not present, we should set the track to seek backward or forward by a “few number of seconds” that makes sense to us. Hence, we use 10 seconds because it is quite a few. In a nutshell, we set the track to seek by seekOffset seconds if it is provided. If it is not provided, we seek by 10 seconds.

To add the seekto functionality to our Media Session API, we include the following snippet:

if ('mediaSession' in navigator) {
  navigator.mediaSession.setActionHandler('seekto', (details) => {
    if (details.fastSeek && 'fastSeek' in alright) {
      alright.fastSeek(details.seekTime);
      return;
    }
    alright.currentTime = details.seekTime;
  });
}

Here, the MediaSessionActionDetails dictionary provides the fastSeek and seekTime properties. fastSeek is basically seek performed rapidly (like fast-forwarding or rewinding) while seekTime is the time the track should seek to. While fastSeek is an optional property, the MediaSessionActionDetails dictionary always provides the seekTime property for the seekto action handler. So fundamentally, we set the track to fastSeek to the seekTime when the property is available and the user fast seeks, while we just set it to the seekTime when the user just seeks to a specified time.

Although I wouldn’t know why one would want to stop a Kendrick song, it won’t hurt to describe the stop action handler of the MediaSession interface:

if ('mediaSession' in navigator) {
  navigator.mediaSession.setActionHandler('stop', () => {
    alright.pause();
    alright.currentTime = 0;
  });
} 

The user invokes the skipad (as in, “skip ad” rather than “ski pad”) action handler when an advertisement is playing and they want to skip it so they can continue listening to Kendrick Lamar’s “Alright” track. If I’m being honest, the complete details of the skipad action handler is out of the scope of my “Media Session API” understanding. Hence, you should probably look that up on your own after reading this article, if you actually want to implement it.

Wrapping up

We should take note of something. Whenever the user plays the track, seeks, or changes the playback rate, we are supposed to update the position state on the interface provided by the Media Session API. What we use to implement this is the setPositionState() method of the mediaSession object, as in the following:

if ('mediaSession' in navigator) {
  navigator.mediaSession.setPositionState({
    duration: alright.duration,
    playbackRate: alright.playbackRate,
    position: alright.currentTime
  });
}

In addition, I would like to remind you that not all browsers of the users would support all the actions. Therefore, it is recommended to set the action handlers in a try...catch block, as in the following:

const actionsAndHandlers = [
  ['play', () => { /*...*/ }],
  ['pause', () => { /*...*/ }],
  ['previoustrack', () => { /*...*/ }],
  ['nexttrack', () => { /*...*/ }],
  ['seekbackward', (details) => { /*...*/ }],
  ['seekforward', (details) => { /*...*/ }],
  ['seekto', (details) => { /*...*/ }],
  ['stop', () => { /*...*/ }]
]
 
for (const [action, handler] of actionsAndHandlers) {
  try {
    navigator.mediaSession.setActionHandler(action, handler);
  } catch (error) {
    console.log(`The media session action, ${action}, is not supported`);
  }
}

Putting everything we have done, we would have the following:

let alright = new HTMLAudioElement();
let u = new HTMLAudioElement();
let forSaleInterlude = new HTMLAudioElement();

const updatePositionState = () => {
  navigator.mediaSession.setPositionState({
    duration: alright.duration,
    playbackRate: alright.playbackRate,
    position: alright.currentTime
  });
}
 
const actionsAndHandlers = [
  ['play', () => {
    alright.play();
    updatePositionState();
  }],
  ['pause', () => { alright.pause(); }],
  ['previoustrack', () => { u.play(); }],
  ['nexttrack', () => { forSaleInterlude.play(); }],
  ['seekbackward', (details) => {
    alright.currentTime = alright.currentTime - (details.seekOffset || 10);
    updatePositionState();
  }],
  ['seekforward', (details) => {
    alright.currentTime = alright.currentTime + (details.seekOffset || 10);
    updatePositionState();
  }],
  ['seekto', (details) => {
    if (details.fastSeek && 'fastSeek' in alright) {
      alright.fastSeek(details.seekTime);
      updatePositionState();
      return;
    }
    alright.currentTime = details.seekTime;
    updatePositionState();
  }],
  ['stop', () => {
    alright.pause();
    alright.currentTime = 0;
  }],
]
 
if ( 'mediaSession' in navigator ) {
  navigator.mediaSession.metadata = new MediaMetadata({
    title: 'Alright',
    artist: 'Kendrick Lamar',
    album: 'To Pimp A Butterfly',
    artwork: [
      { src: 'https://mytechnicalarticle/kendrick-lamar/to-pimp-a-butterfly/alright/96x96', sizes: '96x96', type: 'image/png' },
      { src: 'https://mytechnicalarticle/kendrick-lamar/to-pimp-a-butterfly/alright/128x128', sizes: '128x128', type: 'image/png' },
      // More sizes, like 192x192, 256x256, 384x384, and 512x512
    ]
  });
 
  for (const [action, handler] of actionsAndHandlers) {
    try {
      navigator.mediaSession.setActionHandler(action, handler);
    } catch (error) {
      console.log(`The media session action, ${action}, is not supported`);
    }
  }
}

Here’s a demo of the API:

I implemented six of the actions. Feel free to try the rest during your leisure.

If you view the Pen on your mobile device, notice how it appears on your notification area.

If your smart watch is paired to your device, take a sneak peek at it.

If you view the Pen on Chrome on desktop, navigate to the media hub and play with the media buttons there. The demo even has multiple tracks, so you experiment moving forward/back through tracks.

If you made it this far (or not), thanks for reading and please, on the next app you create with media functionality, implement this API.

The post Give Users Control: The Media Session API appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

With almost 8 billion people in the world, chances are pretty good that everyone has a doppelgänger somewhere out there. Finding My Twin Stranger is a short documentary that follows researchers from the Department of Twin Research at St Thomas’ Hospital as they look for the most identical strangers — people who aren’t biological twins but sure look like they do.

In this documentary, we follow people as they track down their twin stranger across the globe and meet for the first time. They get to know one another and find out about each other’s lives and whether there are any other similarities. While the pairs get to know each other, they are also undergoing a series of tests by the twin-experts at St Thomas’ Hospital. These include measuring similarities of facial features using the latest 3D scanning technology, 2D facial recognition analysis and DNA ancestry testing.

The experts then get 100 people to rate the similarities from photos from most alike to least alike. Taking all of the results into consideration, the twin-experts will then reveal which pair is the most identical.

You can use the site Twin Strangers to find your own doppelgänger — you can see some of their matches here and on Instagram.

See also the fascinating 2018 documentary Three Identical Strangers and Identical Twins Who Look Nothing Alike.

I discovered the solution to my stock imagery problem, ironically, on Unsplash. I started noticing photos from sources like the British Library, Birmingham Museums Trust, and Library of Congress. Who often has archives of public domain imagery? Libraries, museums, and governments. The sites are never a site like Unsplash, but they work well if you have the time and patience to dive through their archives. Plus? You can find some pretty cool photography, art, and illustrations that have a very different vibe than most stock photo resources.

Libraries

There are tons of libraries with license-compatible digital archives, such as the New York Public Library, Library of Congress, The State Library of New South Wales, National Library of Ireland, and many more. Try seeing if a major city with your state has a digital archive. Libraries are great for old photos, advertisements, and illustrations that I’ll use in portfolio site designs.

Museums

Many museums have started digitizing their collections in the past few years, such as the Smithsonian’s National Museum of Asian Art, the Met, and the Art Institute of Chicago. As the museums are often digitizing the work themselves, they have the luxury of releasing the images into the public domain. Museums are a fantastic resource for art, and for photos of objects like ceramics and jewelry that work well in e-commerce mockups.

Governments

US Government agencies like NASA tend to release a ton of their own media for public use, and I’ve discovered that space images look great in blog post mockups. Need some COVID photos? The CDC’s got you covered. Need some black & white nature photos? Check out the National Park Service’s “Open Parks Network.” 

Finding high-quality, totally free stock imagery can be a huge hassle. But I’ve found, with some creativity and some patience, there are far more options than I knew!

The post Unconventional Stock Image Sources appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Election officials in dozens of states representing both political parties said that there was no evidence that fraud or other irregularities played a role in the outcome of the presidential race, amounting to a forceful rebuke of President Trump’s portrait of a fraudulent election.

Over the last several days, the president, members of his administration, congressional Republicans and right wing allies have put forth the false claim that the election was stolen from Mr. Trump and have refused to accept results that showed Joseph R. Biden Jr. as the winner.

But top election officials across the country said in interviews and statements that the process had been a remarkable success despite record turnout and the complications of a dangerous pandemic.

Of course, the Republicans have made no fraud claims about states where they did well. Every Republican who the media projected to be the winner has claimed victory on that basis. And if the Democrats were somehow cheating, wouldn’t they have done far better on down-ballot races — presumably hundreds of thousands of fake ballots for Biden would also have gone for Democratic Senate and House candidates as well? The whole thing is obviously absurd.

(via open culture)

From the NY Times:

The slim, 10-page story is impressionistic, without a real plot. It is the first in a series called “Represent!” that features works of writers “traditionally underrepresented in the mainstream comic book medium,” including people of color or those who are LGBTQ, Marie Javins, an executive editor at DC, said in a statement. It will be available online for free starting Wednesday, at several digital book and comic book retailers.

The main character of “It’s a Bird” is a teenage birder named Jules, who is Black. When Jules tries to peer through his binoculars at birds, he instead sees the faces of Black people who have been killed by the police.

It’s a Bird is available for free from DC Comics. You can read an interview with Cooper and the rest of the creative team (artist Alitha E. Martinez, inker Mark Morales, colorist Emilio Lopez, and letterer Rob Clark Jr.) on the company’s blog. (via open culture)

That’s from a Brazilian duo called Overdriver Duo, who have also done GNR’s Sweet Child O’ Mine, Nirvana’s Smells Like Teen Spirit (on a Frozen-branded uke!), and Every Breath You Take by The Police. (via open culture)

TypeScript is incredibly powerful, but is often difficult to read for beginners and carries the overhead of needing a compilation step before it can run in a browser due to the extra syntax that isn’t valid JavaScript. For many projects this isn’t a problem, but for others this might get in the way of getting work done. Fortunately the TypeScript team has enabled a way to type check vanilla JavaScript using JSDoc.

Setting up a new project

To get TypeScript up and running in a new project, you’ll need NodeJS and npm. Let’s start by creating a new project and running npm init. For the purposes of this article, we are going to be using VShttps://code.visualstudio.comCode as our code editor. Once everything is set up, we’ll need to install TypeScript:

npm i -D typescript

Once that install is done, we need to tell TypeScript what to do with our code, so let’s create a new file called tsconfig.json and add this:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "allowJs": true,
    "checkJs": true,
    "noEmit": true,
    "strict": false,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "esModuleInterop": true
  },
  "include": [ "script", "test" ],
  "exclude": [ "node_modules" ]
}

For our purposes, the important lines of this config file are the allowJs and checkJs options, which are both set to true. These tell TypeScript that we want it to evaluate our JavaScript code. We’ve also told TypeScript to check all files inside of a /script directory, so let’s create that and a new file in it called index.js.

A simple example

Inside our newly-created JavaScript file, let’s make a simple addition function that takes two parameters and adds them together:

function add(x, y) {
  return x + y;
}

Fairly simple, right? add(4, 2) will return 6, but because JavaScript is dynamically-typed you could also call add with a string and a number and get some potentially unexpected results:

add('4', 2); // returns '42'

That’s less than ideal. Fortunately, we can add some JSDoc annotations to our function to tell users how we expect it to work:

/**
 * Add two numbers together
 * @param {number} x
 * @param {number} y
 * @return {number}
 */
function add(x, y) {
  return x + y;
}

We’ve changed nothing about our code; we’ve simply added a comment to tell users how the function is meant to be used and what value should be expected to return. We’ve done this by utilizing JSDoc’s @param and @return annotations with types set in curly braces ({}).

Trying to run our incorrect snippet from before throws an error in VS Code:

In the example above, TypeScript is reading our comment and checking it for us. In actual TypeScript, our function now is equivalent of writing:

/**
 * Add two numbers together
 */
function add(x: number, y: number): number {
  return x + y;
}

Just like we used the number type, we have access to dozens of built-in types with JSDoc, including string, object, Array as well as plenty of others, like HTMLElement, MutationRecord and more.

One added benefit of using JSDoc annotations over TypeScript’s proprietary syntax is that it provides developers an opportunity to provide additional metadata around arguments or type definitions by providing those inline (hopefully encouraging positive habits of self-documenting our code).

We can also tell TypeScript that instances of certain objects might have expectations. A WeakMap, for instance, is a built-in JavaScript object that creates a mapping between any object and any other piece of data. This second piece of data can be anything by default, but if we want our WeakMap instance to only take a string as the value, we can tell TypeScript what we want:

/** @type {WeakMap<object>, string} */
const metadata = new WeakMap();


const object = {};
const otherObject = {};


metadata.set(object, 42);
metadata.set(otherObject, 'Hello world');

This throws an error when we try to set our data to 42 because it is not a string.

Defining our own types

Just like TypeScript, JSDoc allows us to define  and work with our own types. Let’s create a new type called Person that has name, age and hobby properties. Here’s how that looks in TypeScript:

interface Person {
  name: string;
  age: number;
  hobby?: string;
}

In JSDoc, our type would be the following:

/**
 * @typedef Person
 * @property {string} name - The person's name
 * @property {number} age - The person's age
 * @property {string} [hobby] - An optional hobby
 */

We can use the @typedef tag to define our type’s name. Let’s define an interface called Person with required  name (a string)) and age (a number) properties, plus a third, optional property called hobby (a string). To define these properties, we use @property (or the shorthand @prop key) inside our comment.

When we choose to apply the Person type to a new object using the @type comment, we get type checking and autocomplete when writing our code. Not only that, we’ll also be told when our object doesn’t adhere to the contract we’ve defined in our file:

Now, completing the object will clear the error:

Sometimes, however, we don’t want a full-fledged object for a type. For example, we might want to provide a limited set of possible options. In this case, we can take advantage of something called a union type:

/**
 * @typedef {'cat'|'dog'|'fish'} Pet
 */


/**
 * @typedef Person
 * @property {string} name - The person's name
 * @property {number} age - The person's age
 * @property {string} [hobby] - An optional hobby
 * @property {Pet} [pet] - The person's pet
 */

In this example, we have defined a union type called Pet that can be any of the possible options of 'cat', 'dog' or 'fish'. Any other animals in our area are not allowed as pets, so if caleb above tried to adopt a 'kangaroo' into his household, we would get an error:

/** @type {Person} */
const caleb = {
  name: 'Caleb Williams',
  age: 33,
  hobby: 'Running',
  pet: 'kangaroo'
};

This same technique can be utilized to mix various types in a function:

/**
 * @typedef {'lizard'|'bird'|'spider'} ExoticPet
 */


/**
 * @typedef Person
 * @property {string} name - The person's name
 * @property {number} age - The person's age
 * @property {string} [hobby] - An optional hobby
 * @property {Pet|ExoticPet} [pet] - The person's pet
 */

Now our person type can have either a Pet or an ExoticPet.

Working with generics

There could be times when we don’t want hard and fast types, but a little more flexibility while still writing consistent, strongly-typed code. Enter generic types. The classic example of a generic function is the identity function, which takes an argument and returns it back to the user. In TypeScript, that looks like this:

function identity<T>(target: T): T {
  return target;
}

Here, we are defining a new generic type (T) and telling the computer and our users that the function will return a value that shares a type with whatever the argument target is. This way, we can still pass in a number or a string or an HTMLElement and have the assurance that the returned value is also of that same type.

The same thing is possible using the JSDoc notation using the @template annotation:

/**
 * @template T
 * @param {T} target
 * @return {T}
 */
function identity(target) {
  return x;
}

Generics are a complex topic, but for more detailed documentation on how to utilize them in JSDoc, including examples, you can read the Google Closure Compiler page on the topic.

Type casting

While strong typing is often very helpful, you may find that TypeScript’s built-in expectations don’t quite work for your use case. In that sort of instance, we might need to cast an object to a new type. One instance of when this might be necessary is when working with event listeners.

In TypeScript, all event listeners take a function as a callback where the first argument is an object of type Event, which has a property, target, that is an EventTarget. This is the correct type per the DOM standard, but oftentimes the bit of information we want out of the event’s target doesn’t exist on EventTarget — such as the value property that exists on HTMLInputElement.prototype. That makes the following code invalid:

document.querySelector('input').addEventListener(event => {
  console.log(event.target.value);
};

TypeScript will complain that the property value doesn’t exist on EventTarget even though we, as developers, know fully well that an <input> does have a value.

In order for us to tell TypeScript that we know event.target will be an HTMLInputElement, we must cast the object’s type:

document.getElementById('input').addEventListener('input', event => {
  console.log(/** @type {HTMLInputElement} */(event.target).value);
});

Wrapping event.target in parenthesis will set it apart from the call to value. Adding the type before the parenthesis will tell TypeScript we mean that the event.target is something different than what it ordinarily expects.

And if a particular object is being problematic, we can always tell TypeScript an object is @type {any} to ignore error messages, although this is generally considered bad practice depsite being useful in a pinch.

Wrapping up

TypeScript is an incredibly powerful tool that many developers are using to streamline their workflow around consistent code standards. While most applications will utilize the built-in compiler, some projects might decide that the extra syntax that TypeScript provides gets in the way. Or perhaps they just feel more comfortable sticking to standards rather than being tied to an expanded syntax. In those cases, developers can still get the benefits of utilizing TypeScript’s type system even while writing vanilla JavaScript.

The post TypeScript, Minus TypeScript appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Seven books to read in which very little happens. Includes Nicholson Baker's The Mezzanine, which is fantastic. [lithub.com]

The sports writers at the NY Times have come up with some interesting ideas (good and bad) about how to fix professional sports (e.g. too-long baseball games, confusing rules in soccer & football, boring golf). [nytimes.com]

Whoa, a paper that presents evidence of possible human presence in Mexico "as early as 33,000–31,000 years ago", which is more than 15,000 years earlier than the Clovis culture. [nature.com]

The Billionaire Behind Efforts to Kill the U.S. Postal Service. Spoiler warning: it's libertarian dipshit Charles Koch, who has done untold damage to our country and the Earth. [inthepublicinterest.org]

Billie Eilish's bad guy, but played in the major key. "instead of playing it normal i'm the good guy so i play it in the major key, to the screams of music majors everywhere." [youtube.com]

A Small Needful Fact, a poem by Ross Gay about Eric Garner. The last line of this knocked me on my ass. [poets.org]

---

Note: Quick Links are pushed to this RSS feed twice a day. For more immediate service, check out the front page of kottke.org, the Quick Links archive, or the @kottke Twitter feed.

Flores also does covers of pop songs (Billie Eilish’s Bad Guy, Fallin’ by Alicia Keys) and she first captured people’s online attention with a Quechua cover of Michael Jackson’s The Way You Make Me Feel performed when she was 14 years old:

Rosa Chávez Yacila wrote an article for Vice about Flores and her music last year. Her use of Quechua in pop music brought the language out of private spaces into the public.

It’s very common for many Quechua speakers to not teach their children or grandchildren the language because they consider this knowledge as a burden. To explain the shortage of active bilingualism in Peru, the linguist Virginia Zavala uses the concept of “linguistic ideologies,” which are the ideas that people have about languages. For example: French is the language of love; German sounds rough; Italian, Portuguese, and Spanish are similar.

Quechua, similarly to other indigenous languages, is associated with poverty, rural life, and illiteracy. These ideas have been shaped by history and society to the point that people hold on to these beliefs as if they were universal truths. And these “truths” are deeply embedded in their conscious thought process. Value hierarchies also exist with languages. Some are “worth” more than others.

The end result is that many native Quechua speakers believe that using Quechua in public is unnecessary after learning Spanish. Either by shyness or shame, they reserve their maternal tongue for private spaces and intimate conversations.

Like many people, I’ve been thinking a lot over the past few days about race andlaw enforcement, and race relations in this country.

I grew up in a family where I was taught to respect others for who they are. Myparents never had to tell me that the respect I show others should not bedependent on that person’s race, sex, religion, or lifestyle. They taught me torespect others, and showed me that that respect should apply to all.

I also didn’t grow up with a lot of racism around me. I never experienced itmyself, and I don’t recall, as a child, seeing others experience it. I think myexperience was somewhat unusual in that respect, but not as unusual as one mightthink.

Looking back on my childhood, I realize that I didn’t know that much about race.I remember being very young, and thinking that there were two races: white andblack, and that everyone else was probably some mixture of the two. I eventuallylearned more as my experience increased. But as I learned more about race, Istill knew very little about racism.

I think I was naïve in that regard. My impression of contemporary racism, as achild, was that a lot of people of my grandparents’ generation were racist. Andthere were pockets of ignorant people, like the Klan, who were still racisttoday. But other than that, I thought racism was part of our history.

This ignorance was part of my privilege of growing up white. Of course, as Igrew older, I realized that racism was still present. Racism still affectedpeople on a daily basis. But I still couldn’t really appreciate it.

Nearly thirty years ago, when I was almost nine years old, Rodney King wasbeaten by LAPD officers. This incident was filmed, and became public knowledge.I don’t actually remember it happening. I don’t know if my parents intentionallytried to shield my from it, or if it never came up in conversation when I waspaying attention to them. But I’m certain that black children, much younger thanI was, were aware of what happened.

I eventually learned about Rodney King. I was shocked and appalled when I didlearn. Like half of the country who learned about it, I couldn’t believe that itcould happen. I say “half of the country” because the other half of the countryalready knew that this kind of thing happened. They’ve seen it. They’ve seenpolice intimidation and unnecessary force. For many of us, Rodney King was awake-up call, but for others of us who lived with this, it was yet anotherincident.

Six and a half years ago, I married an amazing, intelligent, and beautifulwoman, whose father is black. Over time, I’ve heard from her about herexperiences with racism. She has seen it all her life. To me, it was anexceptional and awful thing. To her, it was an everyday (but still awful) thing.

As I’ve learned more from her, I’ve come to realize a few things:

• There’s no way that I can fully understand her experience.
• Even as I grew up and learned more, I was still woefully ignorant about how people are affected by their own race every single day.
• The only way for me, and people like me, to learn is to listen.

The thing is, I could’ve learned many of these lessons much sooner. I’ve hadplenty of black and brown friends and associates throughout my life. I’ve eventalked to some of them about their experiences with racism, but it had alwaysbeen somewhat superficial conversations. I had never really asked a black personto tell me about how their race affected their life.

But now I have had those conversations with my wife. I can’t possibly fully feelwhat she has felt, but I understand a lot better. I can count on one hand thenumber of times I’ve felt intimidated by a police officer (it’s two, by theway). Many black and brown people can’t even count on one hand the number oftimes in one month.

Mostly, I’ve been pretty overwhelmed by all of this.

This is my son. He’s handsome, and kind, and so smart, and a little rebellious.He’s also my only child who probably can’t “pass for white”. And so, he’s alsothe one I worry about the most. Right now, I can protect him. But twenty yearsfrom now, he could be jogging one night, when someone sees those big, beautifulcurls, and he becomes the next Ahmaud Arbery.

The title of my post is a quote by the Reverend Martin Luther King, Jr. Iincluded this because I’ve seen a lot of comments on social media fromwell-intentioned white folks who are complaining about the rioting, andreferring to those that are causing property damage as “criminals”, or as thePresident has said, “thugs”. It’s hard to understand why someone might go from apeaceful protest to damaging buildings.

But these people are mad. They’ve spent their lives being careful around policeofficers, to try and prevent one of them from losing it, and hurting them.They’ve seen the tape of Rodney King being beaten, but it’s not history forthem. They have continued to see it for the last thirty years since that time.And for most of them, nothing substantive has changed. And now, a black manjogging is killed. And then another black man, while trying to enjoy hisbird-watching hobby, politely asks a woman to put a leash on her dog, as she’ssupposed to do, and is threatened by her as she claims she will lie to thepolice about him, and say he is threatening her life. She knows that saying thathe’s African-American will result in a harsher response from the police.Finally, a man is killed by police, and when they protest, the President callsthem thugs.

They are no longer being heard. George Floyd was not heard by the police as hepled for them to let him breathe, and in his dying moments, cried out for hismother. They are not being heard by the people who need to hear them: thepolice, the mayors, the governors, and the President. They’re scared thatthey’ll accidentally jaywalk and end up like George Floyd. What are they goingto do? They won’t be heard, so they are making themselves heard in the only waythey can figure out how.

Property can be rebuilt, but lives cannot be restored.

If anyone reading this wants to criticize the rioters who are burning downpolice stations, I urge you, before you type that comment on a Facebook post,call up a black or brown friend and talk to them. Let them be heard by someone.

I wish I could send you to an online version of “How to Understand Aliens,” but there doesn’t seem to be one. You can see the beginning in accursed snippet view here, but that’s not much help. You can read the article here (thanks, Owlmirror!). I’ll copy out a short passage that will give you some idea; the whole thing is well done, as one would expect, and hopefully gave some readers (and writers) a better idea of how language works:

Space linguists could gain valuable practice in unravelling bizarre languages by having a preliminary workout on a terrestrial language before venturing into extra-terrestrial contact. For instance, a cadet linguist thrown amongst a tribe of Australian Aborigines would be able to get an idea of the variety of similar meanings a word can have when he learned that gargal could mean, firstly, the upper part of the human arm as it meets the body; secondly, the lower part of a branch, where it meets the trunk of a tree; and thirdly, the mouth of a stream where it flows into a larger river. And of how the meaning of a word can be extended to apply to new situations: the word for ‘hollow log’, maralu, being taken over to apply to ‘shirt’ when the aborigines first came into contact with white men wearing this novel garment.

This is my favorite sort of marketing. Some of the products aren’t free, like the React PDF … Read article “Phuoc Nguyen’s One Page Wonders”

The post Phuoc Nguyen’s One Page Wonders appeared first on CSS-Tricks.

There’s no question that forms on mobile devices can be time-consuming and tedious to fill in, but by properly configuring inputs, we can ensure that the data entry process is as seamless as possible for our users. Let’s take a look at some examples and best practices we can use to create better user experiences on mobile devices.

Using the correct input type

This is the easiest thing to get right. Input types, like email, tel, and url, are well-supported across browsers. While the benefit of using a type, like tel over the more generic text, might be hard to see on desktop browsers, it’s immediately apparent on mobile.

Choosing the appropriate type changes the keyboard that pops up on Android and iOS devices when a user focuses the field. For very little effort, just by using the right type, we will show custom keyboards for email, telephone numbers, URLs, and even search inputs. 

One thing to note is that both input type="email" and input type="url" come with validation functionality, and modern browsers will show an error tooltip if their values do not match the expected formats when the user submits the form. If you’d rather turn this functionality off, you can simply add the novalidate attribute to the containing form.

A quick detour into date types

HTML inputs comprise far more than specialized text inputs — you also have radio buttons, checkboxes, and so on. For the purposes of this discussion, though, I’m mostly talking about the more text-based inputs. 

There is a type of input that sits in the liminal space between the more free-form text inputs and input widgets like radio buttons: date. The date input type comes in a variety of flavors that are well-supported on mobile, including date, time, datetime-local, and month. These pop up custom widgets in iOS and Android when they are focused. Instead of triggering a specialized keyboard, they show a select-like interface in iOS, and various different types of widgets on Android (where the date and time selectors are particularly slick). 

I was excited to start using native defaults on mobile, until I looked around and realized that most major apps and mobile websites use custom date pickers rather than native date input types. There could be a couple reasons for this. First, I find the native iOS date selector to be less intuitive than a calendar-type widget. Second, even the beautifully-designed Android implementation is fairly limited compared to custom components — there’s no easy way to input a date range rather than a single date, for instance. 

Still, the date input types are worth checking out if the custom datepicker you’re using doesn’t perform well on mobile. If you’d like to try out the native input widgets on iOS and Android while making sure that desktop users see a custom widget instead of the default dropdown, this snippet of CSS will hide the calendar dropdown for desktop browsers that implement it:

::-webkit-calendar-picker-indicator {
  display: none;
}

One final thing to note is that date types cannot be overridden by the inputmode attribute, which we’ll discuss next.

Why should I care about inputmode?

The inputmode attribute allows you to override the mobile keyboard specified by the input’s type and directly declare the type of keyboard shown to the user. When I first learned about this attribute, I wasn’t impressed — why not just use the correct type in the first place? But while inputmode is often unnecessary, there are a few places where the attribute can be extremely helpful. The most notable use case that I’ve found for inputmode is building a better number input.

While some HTML5 input types, like url and email, are straightforward, input type="number" is a different matter. It has some accessibility concerns as well as a somewhat awkward UI. For example, desktop browsers, like Chrome, show tiny increment arrows that are easy to trigger accidentally by scrolling.

So here’s a pattern to memorize and use going forwards. For most numeric inputs, instead of using this: 

<input type="number" />

…you actually want to use this:

<input type="text" inputmode="decimal" />

Why not inputmode="numeric" instead of inputmode="decimal" ? 

The numeric and decimal attribute values produce identical keyboards on Android. On iOS, however, numeric displays a keyboard that shows both numbers and punctuation, while decimal shows a focused grid of numbers that almost looks exactly like the tel input type, only without extraneous telephone-number focused options. That’s why it’s my preference for most types of number inputs.

Christian Oliff has written an excellent article dedicated solely to the inputmode attribute.

Don’t forget autocomplete

Even more important than showing the correct mobile keyboard is showing helpful autocomplete suggestions. That can go a long way towards creating a faster and less frustrating user experience on mobile.

While browsers have heuristics for showing autocomplete fields, you cannot rely on them, and should still be sure to add the correct autocomplete attribute. For instance, in iOS Safari, I found that an input type="tel" would only show autocomplete options if I explicitly added a autocomplete="tel" attribute.

You may think that you are familiar with the basic autocomplete options, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values! Did you know that autocomplete="one-time-code" can make a phone verification user flow super smooth?

Speaking of autocomplete…

I’d like to mention one final element that allows you to create your own custom autocomplete functionality: datalist. While it creates a serviceable — if somewhat basic — autocomplete experience on desktop Chrome and Safari, it shines on iOS by surfacing suggestions in a convenient row right above the keyboard, where the system autocomplete functionality usually lives. Further, it allows the user to toggle between text and select-style inputs.

On Android, on the other hand, datalist creates a more typical autocomplete dropdown, with the area above the keyboard reserved for the system’s own typeahead functionality. One possible advantage to this style is that the dropdown list is easily scrollable, creating immediate access to all possible options as soon as the field is focused. (In iOS, in order to view more than the top three matches, the user would have to trigger the select picker by pressing the down arrow icon.)

You can use this demo to play around with datalist:

And you can explore all the autocomplete options, as well as input type and inputmode values, using this tool I made to help you quickly preview various input configurations on mobile.

In summary

When I’m building a form, I’m often tempted to focus on perfecting the desktop experience while treating the mobile web as an afterthought. But while it does take a little extra work to ensure forms work well on mobile, it doesn’t have to be too difficult. Hopefully, this article has shown that with a few easy steps, you can make forms much more convenient for your users on mobile devices.

The post Better Form Inputs for Better Mobile User Experiences appeared first on CSS-Tricks.

Whether you’re just getting started with Git, or you know your way around a command line, it’s always nice to brush up on your skills, which is why we’ve gathered 15 methods to improve your Git-based workflow.

1. Git aliases

One of the most impactful ways to improve your daily workflow is to create aliases for common commands to save you some time in the terminal.

You can use the following commands to create aliases for the most-used Git commands, checkout, commit and branch.

git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch

Instead of typing git checkout master, you only need to type git co master.

You could also edit these commands or add more by modifying the ~/.gitconfig file directly:

[alias]
    co = checkout
    ci = commit
    br = branch

2. See the repository status in your terminal’s prompt

If you’d like to visualize the status of your repository, you can run git-prompt.sh (you can download it and follow the instructions to use it in your system). If you're using Linux and have installed Git with your package manager, it may already be present on your system, likely under /etc/bash_completion.d/.

You can replace your standard shell prompt with something a bit more exciting:

Taken from oh-my-zsh's themes wiki.

3. Compare commits from the command line

A simple way to compare the differences between commits or versions of the same file is to use the git diff command.

If you want to compare the same file between different commits, you run the following:

$ git diff $start_commit..$end_commit -- path/to/file

If you want to compare the changes between two commits:

$ git diff $start_commit..$end_commit

These commands will open the diff view inside the terminal, but if you prefer to use a more visual tool to compare your diffs, you can use git difftool. Meld is a useful viewer/editor to visually compare diffs.

To configure Meld:

$ git config --global diff.tool git-meld

To start viewing the diffs:

$ git difftool $start_commit..$end_commit -- path/to/file
# or
$ git difftool $start_commit..$end_commit

4. Stashing uncommitted changes

If you’re ever working on a feature and need to do an emergency fix on the project, you could run into a problem. You don’t want to commit an unfinished feature, and you also don’t want to lose current changes. The solution is to temporarily remove these changes with the Git stash command:

$ git stash

The git stash command hides changes, giving you a clean working directory and the ability to switch to a new branch to make updates, without having to commit a meaningless snapshot in order to save the current state.

Once you’re done working on a fix and want to revisit your previous changes, you can run:

$ git stash pop

And your changes will be recovered. �

If you no longer need those changes and want to clear the stash stack, you can do so with:

$ git stash drop

5. Pull frequently

If you’re using GitLab Flow, then you’re working on feature branches. Depending on how long your feature takes to implement, there might be several changes made to the master branch. In order to avoid major conflicts, you should frequently pull the changes from the master branch to your branch to resolve any conflicts as soon as possible and to make merging your branch to master easier.

6. Autocomplete commands

Using completion scripts, you can quickly create the commands for bash, tcsh and zsh. If you want to type git pull, you can type just the first letter with git p followed by Tab will show the following:

pack-objects   -- create packed archive of objects
pack-redundant -- find redundant pack files
pack-refs      -- pack heads and tags for efficient repository access
parse-remote   -- routines to help parsing remote repository access parameters
patch-id       -- compute unique ID for a patch
prune          -- prune all unreachable objects from the object database
prune-packed   -- remove extra objects that are already in pack files
pull           -- fetch from and merge with another repository or local branch
push           -- update remote refs along with associated objects

To show all available commands, type git in your terminal followed by Tab+ Tab.

7. Set a global .gitignore

If you want to avoid committing files like .DS_Store or Vim swp files, you can set up a global .gitignore file.

Create the file:

touch ~/.gitignore

Then run:

git config --global core.excludesFile ~/.gitignore

Or manually add the following to your ~/.gitconfig:

[core]
  excludesFile = ~/.gitignore

You can create a list of the things you want Git to ignore. To learn more, visit the gitignore documentation.

8. Enable Git’s autosquash feature by default

Autosquash makes it easier to squash commits during an interactive rebase. It can be enabled for each rebase using git rebase -i --autosquash, but it's easier to turn it on by default.

git config --global rebase.autosquash true

Or manually add the following to your ~/.gitconfig:

[rebase]
  autosquash = true

9. Delete local branches that have been removed from remote on fetch/pull

You likely have stale branches in your local repository that no longer exist in the remote one. To delete them in each fetch/pull, run:

git config --global fetch.prune true

Or manually add the following to your ~/.gitconfig:

[fetch]
  prune = true

10. Use Git blame more efficiently

Git blame is a handy way to discover who changed a line in a file. Depending on what you want to show, you can pass different flags:

$ git blame -w  # ignores white space
$ git blame -M  # ignores moving text
$ git blame -C  # ignores moving text into other files

11. Add an alias to check out merge requests locally

A merge request contains all the history from a repository, and the additional commits added to the branch associated with the MR. You can check out a public merge request locally even if the source project is a fork (even a private fork) of the target project.

To check out a merge request locally, add the following alias to your ~/.gitconfig:

[alias]
  mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -

Now you can check out a merge request from any repository and any remote. For example, to check out the merge request with ID 5 as shown in GitLab from the upstream remote, run:

git mr upstream 5

This will fetch the merge request into a local mr-upstream-5 branch and check it out. In the above example, upstream is the remote that points to GitLab which you can find out by running git remote -v.

12. An alias of HEAD

Breaking news: @ is the same as HEAD. Using it during a rebase is a lifesaver:

git rebase -i @~2

13. Resetting files

You’re modifying your code when you suddenly realize that the changes you made are not great, and you’d like to reset them. Rather than clicking undo on everything you edited, you can reset your files to the HEAD of the branch:

$ git reset --hard HEAD

Or if you want to reset a single file:

$ git checkout HEAD -- path/to/file

Now, if you already committed your changes, but still want to revert back, you can use:

$ git reset --soft HEAD~1

14. The git-open plugin

If you’d like to quickly visit the website that hosts the repository you’re on, you’ll need git-open.

Install it and take it for a spin by cloning a repository from GitLab.com. From your terminal, navigate to the repository and run git open to be transferred to the project’s page on GitLab.com.

The plugin works by default for projects hosted on GitLab.com, but you can also use it with your own GitLab instances. In that case, set up the domain name with:

git config gitopen.gitlab.domain git.example.com

You can open different remotes and branches if they have been set up. You can learn more by checking out the examples section.

15. The git-extras plugin

If you want to elevate Git with more commands, try out the git-extras plugin, which includes git info (show information about the repository) and git effort (number of commits per file).

Learn more about Git

We’re excited to announce that Brendan O’Leary, senior developer evangelist, will create 15 videos to celebrate Git's anniversary over the next several months. He’ll focus on a variety of topics, from rebasing and merging to cherry-picking and branching. Take a look at the first video in the series. �

Cover image by Brooke Lark on Unsplash

During the month of April, HBO is streaming dozens of shows, documentaries & movies for free via HBO GO & HBO NOW. Shows include The Wire (my personal fave), Succession, VEEP, The Sopranos, True Blood, Six Feet Under, and Silicon Valley. HBO usually offers a few things outside their paywall, but never anything this extensive.

Please remember: The idea that when disaster strikes people panic and social order collapses is very popular. It is also a myth. A huge research literature shows disaster makes people *more* pro-social. They cooperate. They support each other. They’re better than ever.

But the myth matters because it can lead people to take counterproductive actions and adopt policies. The simple truth is we are a fantastically social species and threats only fuel our instinct to pro-social behaviour.

Incidentally, this point is made, and is forgotten, after every disaster. Remember 9/11? Everyone was astonished that snarling, greedy, individualistic New Yorkers were suddenly behaving like selfless saints. No need for surprise. That’s humanity. That’s how we roll.

A reader suggested I check out Rebecca Solnit’s writing on the topic, and indeed she wrote an entire book in 2010 about this: A Paradise Built in Hell: The Extraordinary Communities That Arise in Disaster. Solnit recently spoke to CBC Radio about her research.

I had learned by reading the oral histories of the 1906 earthquake, and by reading the wonderful disaster sociologists in a field that begins in part with Samuel Prince, looking at the Halifax Explosion in 1917 … that actually in disasters, most people are altruistic, brave, communitarian, generous and deeply creative in rescuing each other, creating the conditions for success of survival and often creating these little disaster utopias where everyone feels equal. Everyone feels like a participant.

It’s like a reset, when you turn the machine on and off and on again, that our basic default setting is generous and communitarian and altruistic. But what’s shocking is the incredible joy people often seem to have, when they describe that sense of purpose, connection, community agency they found. It speaks to how deeply we desire something we mostly don’t have in everyday life. That’s a kind of social, public love and power, above and beyond the private life.

I’ve put this 2016 episode of On Being with Solnit on my to-listen list.

The amazing thing about the 1989 earthquake — it was an earthquake as big as the kind that killed thousands of people in places like Turkey and Mexico City, and things like that. But partly, because we have good infrastructure, about 50 people died, a number of people lost their homes, everybody was shaken up. But what was so interesting for me was that people seemed to kind of love what was going on.

That same year in the aftermath of the election, she wrote an essay called How to Survive a Disaster.

I landed in Halifax, Nova Scotia, shortly after a big hurricane tore up the city in October of 2003. The man in charge of taking me around told me about the hurricane-not the winds at more than a hundred miles an hour that tore up trees, roofs, telephone poles, not the seas that rose nearly ten feet, but the neighbors. He spoke of the few days when everything was disrupted and lit up with happiness as he did so. In his neighborhood all the people had come out of their houses to speak with each other, aid each other, to improvise a community kitchen, make sure the elders were okay, and spend time together, no longer strangers. “Everybody woke up the next morning and everything was different,” he mused. “There was no electricity, all the stores were closed, no one had access to media. The consequence was that everyone poured out into the street to bear witness. Not quite a street party, but everyone out at once-it was a sense of happiness to see everybody even though we didn’t know each other.” His joy struck me powerfully.

More reading material on this, via Gardner: Disaster Mythology and Fact: Hurricane Katrina and Social Attachment, Psychological disaster myths in the perception and management of mass emergencies, There Goes Hurricane Florence; Here Come the Disaster Myths, and 5 Most Common (and Most Dangerous) Disaster Myths.

Note: A version of this post first appeared in Noticing, the kottke.org newsletter. You can subscribe here.

In cases of emergency, many organizations need a quick way to publish critical information. But exisiting (CMS) websites are often unable to handle sudden spikes in traffic.

What’s so special about this boilerplate? Well, it does smart stuff like:

• generates a static site using Eleventy,
• uses minimal markup with inlined CSS,
• aims to transmit everything in the first connection roundtrip (~14KB),
• progressively enables offline-support with Service Workers,
• uses Netlify CMS for easy content editing, and
• provides one-click deployment via Netlify to get off the ground quickly

The example website that Max built with this boilerplate is shockingly fast and I would go one step further to argue that all websites should feel as fast as this, not just websites that are useful in an emergency.

Direct Link to Article — Permalink

The post Emergency Website Kit appeared first on CSS-Tricks.

Here's the one-liner in use:

<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🎯</text></svg>">

Demo Project

I made a quick little demo project so you can see it at work. See the deployed project to actually see the favicons. That works in Firefox and Chrome. Safari only does those "mask" style icons in SVG so this doesn't work there. Maybe it could though? I dunno I'll let you try it.

Here's a video in case you just wanna see it.

Related Concepts

• Ada Rose Cannon added a badge that can increment.
• Taylor Hunt dropped some code on how he uses the current Git branch name to create an SVG favicon (related to the "different favicon for development" idea)
• You could duck a prefers-color-scheme media query in the SVG if you wanted to do something special for dark mode (although emojis generally work well on any background)

The post Emojis as Favicons appeared first on CSS-Tricks.

Many companies and organizations are working to make movies, TV shows, books, and other entertainment free (or cheaper, at least) for folks stuck at home during the coronavirus outbreak. Sling TV has free movies and TV shows, 24 Hour Fitness made some of its premium features free for everyone, and now the makers of Sesame Street have made over 100 eBooks free on various platforms.

Sesame Workshop announced yesterday that "over 110" free Sesame Street eBooks are now available on all major platforms, including Amazon Kindle, Apple Books, Barnes & Noble Nook, Google Play, and Kobo.

Sesame Street eBooks are free on Amazon, Google Play, and other platforms was written by the awesome team at Android Police.

Update the status of the event

• If the event has been canceled: Set the eventStatus property to EventCancelled and keep the original date in the startDate of the event.
• If the event has been postponed (but the date isn't known yet): Keep the original date in the startDate of the event until you know when the event will take place and update the eventStatus to EventPostponed. The startDate property is required to help identify the unique event, and we need the date original startDate until you know the new date. Once you know the new date information, change the eventStatus to EventRescheduled and update the startDate and endDate with the new date information.
• If the event has been rescheduled to a later date: Update the startDate and endDate with the relevant new dates. Optionally, you can also mark the eventStatus field as EventRescheduled and add the previousStartDate.
• If the event has moved from in-person to online-only: Optionally update the eventStatus field to indicate the change with EventMovedOnline. 

Mark events as online only

• Set the location to the VirtualLocation type.
• Set the eventAttendanceMode property to OnlineEventAttendanceMode.

Update Google when your event changes

Partial Clone is a new feature of Git that replaces Git LFS and makes working with very large repositories better by teaching Git how to work without downloading every file. Partial Clone has been years in the making, with code contributions from GitLab, GitHub, Microsoft and Google. Today it is experimentally available in Git and GitLab, and can be enabled by administrators (docs).

Partial Clone speeds up fetching and cloning because less data is transferred, and reduces disk usage on your local computer. For example, cloning gitlab-com/www-gitlab-com using Partial Clone (--filter=blob:none) is at least 50% faster, and transfers 70% less data.

Note: Partial Clone is one specific performance optimization for very large repositories. Sparse Checkout is a related optimization that is particularly focused on repositories with tremendously large numbers of files and revisions such as Windows code base.

A brief history of large files

"What about Git LFS?" you may ask. Doesn't LFS stand for "large file storage"?

Previously, extra tools were required to store large files in Git. In 2010, git-annex was released, and five years later in 2015, Git LFS was released. Both git-annex and Git LFS added large file support to Git in a similar way: Instead of storing a large file in Git, store a pointer file that links to the large file. Then, when someone needs a large file, they can download it on-demand using the pointer.

The criticism of this approach is that there are now two places to store files, in Git or in Git LFS. Which means that everyone must remember that big files need to go in Git LFS to keep the repository small and fast. There are downsides to this approach. Besides being susceptible to human error, the pointer encodes decisions based on bandwidth and file type into the structure of the repository that influence all the people using the repository. Our assumptions about bandwidth and storage are likely to change over time, and vary by the location, but decisions encoded in the repository are not flexible. Administrators and developers alike benefit from flexibility in where to store large files, and which files to download.

Partial Clone solves these problems by removing the need for two classes of storage, and special pointers. Let's walk through an example to understand how.

Getting started with Partial Clone

Let's continue to use gitlab-com/www-gitlab-com as an example project, since it has quite a lot of images. For a larger repository, like a video game with detailed textures and models, the benefits will be even more significant.

Instead of a vanilla git clone, we will include a filter spec which controls what is excluded when fetching data. In this situation, we just want to exclude large binary files. I've included --no-checkout so we can more clearly observe what is happening.

git clone --filter=blob:none --no-checkout git@gitlab.com/gitlab-com/www-gitlab-com.git
# Cloning into 'www-gitlab-com'...
# remote: Enumerating objects: 624541, done.
# remote: Counting objects: 100% (624541/624541), done.
# remote: Compressing objects: 100% (151886/151886), done.
# remote: Total 624541 (delta 432983), reused 622339 (delta 430843), pack-reused 0
# Receiving objects: 100% (624541/624541), 74.61 MiB | 8.14 MiB/s, done.
# Resolving deltas: 100% (432983/432983), done.

Above we explicitly told Git not to checkout the default branch. Normally checkout doesn't require fetching any data from the server, because we have everything locally. When using Partial Clone, since we are deliberately not downloaded everything, Git will need to fetch any missing files when doing a checkout.

git checkout master
# remote: Enumerating objects: 12080, done.
# remote: Counting objects: 100% (12080/12080), done.
# remote: Compressing objects: 100% (11640/11640), done.
# remote: Total 12080 (delta 442), reused 9773 (delta 409), pack-reused 0
# Receiving objects: 100% (12080/12080), 1.10 GiB | 8.49 MiB/s, done.
# Resolving deltas: 100% (442/442), done.
# Updating files: 100% (12342/12342), done.
# Filtering content: 100% (3/3), 131.24 MiB | 4.73 MiB/s, done.

If we checkout a different branch or commit, we'll need to download more missing files.

git checkout 92d1f39b60f957d0bc3c5621bb3e17a3984bdf72
# remote: Enumerating objects: 1968, done.
# remote: Counting objects: 100% (1968/1968), done.
# remote: Compressing objects: 100% (1953/1953), done.
# remote: Total 1968 (delta 23), reused 1623 (delta 15), pack-reused 0
# Receiving objects: 100% (1968/1968), 327.44 MiB | 8.83 MiB/s, done.
# Resolving deltas: 100% (23/23), done.
# Updating files: 100% (2255/2255), done.
# Note: switching to '92d1f39b60f957d0bc3c5621bb3e17a3984bdf72'.

Git remembers the filter spec we provided when cloning the repository so that fetching updates will also exclude large files until we need them.

git config remote.origin.promisor
# true

git config remote.origin.partialclonefilter
# blob:none

When committing changes, you simply commit binary files like you would any other file. There is no extra tool to install or configure, no need to treat big files differently to small files.

Network and Storage

If you are already using Git LFS today, you might be aware that large files are stored and transferred differently to regular Git objects. On GitLab.com, Git LFS objects are stored in object storage (like AWS S3) rather than fast attached storage (like SSD), and transferred over HTTP even when using SSH for regular Git objects. Using object storage has the advantage of reducing storage costs for large binary files, while using simpler HTTP requests for large downloads allows the possibility of resumable and parallel downloads.

Partial Clone already supports more than one remote, and work is underway to allow large files to be stored in a different location such as object storage. Unlike Git LFS, however, the repository or instance administrator will be able to choose which objects should be stored where, and change this configuration over time if needed.

Follow the epic for improved large file storage to learn more and follow our progress.

Performance

When fetching new objects from the Git server using a filter spec to exclude objects from the response, Git will check each object and exclude any that match the filter spec. In Git 2.25, the most recent version, filtering has not been optimized for performance.

Jeff King (Peff) (GitHub) recently contributed performance improvements for blob size filtering, which will likely be included in Git 2.26, and our plan is to include it in GitLab 12.10 release.

Optimizing the sparse filter spec option (--filter:sparse), which filters based on file path is more complex because blobs, which contain the file content, do not include file path information. The directory structure of a repository is stored in tree objects.

Follow the epic for partial clone performance improvements to learn more and follow our progress.

Usability

One of the drawbacks of Git LFS was that it required installing an additional tool. In comparison, Partial Clone does not require any additional tools. However, it does require learning new options and configurations, such as to clone using the --filter option.

We want to make it easy for people get their work done, who simply desire Git to just work. They shouldn't need to work out which is the optimal blob size filter spec for a project? Or what even is a filter spec? While Partial Clone remains experimental, we haven't made any changes to the GitLab interface to highlight Partial Clone, but we are investigating this and welcome your feedback. Please join the conversation on this issue.

File locking and tool integrations

Any conversation of large binary files, particularly in regards to video games is incomplete without discussing file locking and tooling integrations.

Unlike plain text source code, resolving conflicts between different versions of a binary file is often impossible. To prevent conflicts in binary file editing, an exclusive file lock is used, meaning only one person at a time can edit a file, regardless of branches. If conflicts can't be resolved, allowing multiple versions of a file to be created in parallel on different branches is a bug, not a feature. GitLab already has basic file locking support, but it is really only useful for plain text because it only applies to the default branch, and is not integrated with any local tools.

Local tooling integrations are important for binary asset workflows, to automatically propagate file locks to the local development environment, and to allow artists to work on assets without needing to use Git from the command line. Propagating file locks quickly to local development environments is also important because it prevents work from being wasted before it even happens.

Follow the file locking and integrations epics for more information about what we're working on.

Conclusion

Large files are necessary for many projects, and Git will soon support this natively, without the need for extra tools. Although Partial Clone is still an experimental feature, we are making improvements with every release and the feature is now ready for testing.

Thank you to the Git community for your work over the past years on improving support for enormous repositories. Particularly, thank you to Jeff King (GitHub) and Christian Couder (senior backend engineer on Gitaly at GitLab) for your early experimentation with partial clone, Jonathan Tan (Google) and Jeff Hostetler (Microsoft) for contributing the first implementation of Partial Clone and promisor remotes, and the many others who've also contributed.

If you are already using partial clone, or would like to help us test partial clone on a large project, please get in touch with me, James Ramsay (group manager, product for Create at GitLab), Jordi Mon (senior product marketing manager for Dev at GitLab), or your account manager.

Cover image by Simon Boxus on Unsplash

The First Presidency of The Church of Jesus Christ of Latter-day Saints sent the following letter Wednesday to members of the Church worldwide. The letter announces a significant change to service in missionary training centers in Provo, Utah, and Preston, England.

The First Presidency of The Church of Jesus Christ of Latter-day Saints sent the following letter Wednesday to members of the Church worldwide. The letter details a notable restriction on large gatherings of Latter-day Saints.

The First Presidency of The Church of Jesus Christ of Latter-day Saints sent the following letter today to members of the Church worldwide. 

Here's what I wrote:

.site-footer__nav a:hover > svg ellipse:first-child { }

At the end of it, I honestly couldn't even explain what it does to myself. LOL, that probably means there was a better way to write it.

But Hugo Giraudel has this handy new tool that will explain any selector you throw at it.

Here's how it explained mine:

An <ellipse> element provided it is the first child of its parent somewhere
… within a <svg> element
… itself directly within an <a> element provided it is hovered
… itself somewhere
… within an element with class site-footer__nav.

Bravo! It even spits out the specificity of the selector to boot. 👏

Direct Link to Article — Permalink

The post Selectors Explained appeared first on CSS-Tricks.

My hit series of DJ videos exploring pairs of songs that aren’t direct covers or rip-offs, but have similar melodies, riffs, or chord progressions and just fit together nicely.

Each video is about a minute long and features him playfully mixing two or more songs together that sound very similar. Here’s one of the early episodes, featuring Hot Fun in the Summertime by Sly & the Family Stone and Misunderstanding by Genesis:

T.I.’s Whatever You Like and Zombie by The Cranberries:

Whomst among us wouldn’t go nuts if the DJ laid this down at the club — M83’s Midnight City & Rihanna’s Diamonds:

And this one made me LOL — Draggin’ the Line by Tommy James mixes really well with the Baby Back Ribs song from the Chili’s commercial:

What a great combination of creativity and craft. Watching stuff like this always makes this non-musical person want to make some music. (via @hoodinternet)

• Jason Lengstorf and Zach Leatherman did a Learn with Jason episode on it.
• Reginald Hunt has a big ol' guide on it.
• Phil Hawksworth has all these starters for it, like EleventyOne and ElevenTail.
• Andy Bell has Hylia, another starter that's preconfigured with Netlify CMS and a bunch of other goodies.

The post Eleventy Love appeared first on CSS-Tricks.

A new six-episode podcast series from the editors of The Joseph Smith Papers analyzes Joseph Smith’s first encounter with Deity (known by The Church of Jesus Christ of Latter-day Saints as the First Vision) — an event that occurred 200 years ago this spring.

The story on alternate social media networks offers a nice media archaeology of all these sites; how they were covered and explained in the moment. Check out this explanation of Friendster in SF Weekly from August 13, 2003:

“Your induction into Friendster starts out innocently enough: You receive an e-mail invitation from a friend. It doesn’t cost anything to join, so you give it a whirl. You answer questions about your profession, favorite books, movies, music, and other interests, then upload a digital photo of yourself.

Thumbnail versions of your friends’ photos appear on your profile page like a collection of trading cards. Clicking on their pictures takes you to their pages, where you can see all of their friends, and so on. Even with only a few friends, you find that — through friends of friends — you suddenly have access to a social network of thousands of people.”

It’s a pretty common story what happened to all these sites; either they took the money, and got mismanaged, driving off whatever users they had in the first place, or they didn’t take the money, which meant they could never stay usable enough to support all of the users they were taking on.

A few other common threads: a fear of porn, other lewd behavior, and Yik Yak -style harassment. In short, it’s hard to make a social media site actually go big. You need money, a vanilla rep, ruthlessness, and more money. In the end, Facebook really was in the right place at the right time.

The one thing this doesn’t do is some deep left-field speculating, like, what if Google had seen what it had in Blogger to create Facebook before Facebook? Or Yahoo had figured it out with version X of whatever asset Yahoo had? There are social networks, real or latent, bigger than the social media graveyeard — some of the pieces are still here.

One of the most exciting things about writing How To was that, for a few chapters, I was able to reach out to some extremely cool people who were willing to apply their unique expertise to ridiculous tasks. Among those who generously agreed to help was Serena Williams.

Here’s a portion of the chapter “How to Catch a Drone”, in which Serena helped test whether tennis serves could be an effective countermeasure against flying robots … by taking a drone out onto a court and hitting tennis balls at it until it crashed.

How to Catch a Drone

A wedding-photography drone is buzzing around above you. You don’t know what it’s doing there and you want it to stop.

Let’s suppose you have a garage full of sports equipment— baseballs, tennis rackets, lawn darts, you name it. Which sport’s projectiles would work best for hitting a drone? And who would make the best anti-drone guard? A baseball pitcher? A basketball player? A tennis player? A golfer? Someone else?

There are a few factors to consider — accuracy, weight, range, and projectile size.

One sport I couldn’t find good data on was tennis. I found some studies of tennis pro accuracy, but they involved hitting targets marked on the court, rather than in the air.

So I reached out to Serena Williams.

To my pleasant surprise, she was happy to help out. Her husband, Alexis, offered a sacrificial drone, a DJI Mavic Pro 2 with a broken camera. They headed out to her practice court to see how effective the world’s best tennis player would be at fending off a robot invasion.

The few studies I could find suggested tennis players would score relatively low com- pared to athletes who threw projectiles— more like kickers than pitchers. My tentative guess was that a champion player would have an accuracy ratio around 50 when serving, and take 5–7 tries to hit a drone from 40 feet. (Would a tennis ball even knock down a drone? Maybe it would just ricochet off and cause the drone to wobble! I had so many questions.)

Alexis flew the drone over the net and hovered there, while Serena served from the baseline.

Her first serve went low. The second zipped past the drone to one side.

The third serve scored a direct hit on one of the propellers. The drone spun, momentarily seemed like it might stay in the air, then flipped over and smashed into the court. Serena started laughing as Alexis walked over to investigate the crash site, where the drone lay on the court near several propeller fragments.

I had expected a tennis pro would be able to hit the drone in five to seven tries; she got it in three.

For more on anti-drone strategies, sports projectile accuracy, a discussion with a robot ethicist about whether hitting a drone with a tennis ball is wrong, and many other topics, check out How To: Absurd Scientific Advice for Common Real-World Problems, available September 3^rd (preorder: Amazon, Barnes & Noble, IndieBound, and Apple Books).

I’m really excited about it! Here’s the first preview of what’s inside:

Chapter list

• How to Jump Really High
• How to Throw a Pool Party
• How to Dig a Hole
• How to Play the Piano
• How to Make an Emergency Landing
• How to Cross a River

• How to Move
• How to Keep Your House from Moving
• How to Build a Lava Moat
• How to Throw Things
• How to Play Football
• How to Predict the Weather
• How to Play Tag
• How to Ski

• How to Mail a Package
• How to Power Your House (on Earth)
• How to Power Your House (on Mars)
• How to Make Friends
• How to Send a File
• How to Charge Your Phone
• How to Take a Selfie

• How to Catch a Drone
• How to Tell If You’re a Nineties Kid
• How to Win an Election
• How to Decorate a Tree
• How to Get Somewhere Fast
• How to Be On Time
• How to Dispose of This Book

In addition to the main chapters, the book also features short guides on topics including tornado chasing, dog walking, and highway engineering.

Introduction

This is a book of bad ideas.

At least, most of them are bad ideas. It’s possible some good ones slipped through the cracks. If so, I apologize.

Some ideas that sound ridiculous turn out to be revolutionary. Smearing mold on an infected cut sounds like a terrible idea, but the discovery of penicillin showed that it could be a miracle cure. On the other hand, the world is full of disgusting stuff that you could smear on a wound, and most of them won’t make it better. Not all ridiculous ideas are good. So how do we tell the good ideas from the bad? We can try them and see what happens. But sometimes, we can use math, research, and things we already know to work out what will happen if we do.

When NASA was planning to send its car-size Curiosity rover to Mars, they had to figure out how to land it gently on the surface. Previous rovers had landed using parachutes and air bags, so NASA engineers considered this approach with Curiosity, but the rover was too large and heavy for parachutes to slow it down enough in Mars’s thin atmosphere. They also thought about mounting rockets on the rover to let it hover and touch down gently, but the exhaust would create dust clouds that would obscure the surface and make it hard to land safely.

Eventually, they came up with the idea of a “sky crane” —a vehicle that would hover high above the surface using rockets while lowering Curiosity to the ground on a long tether. This sounded like a ridiculous idea, but every other idea they could come up with was worse. The more they looked at the sky crane idea, the more plausible it seemed. So they tried it, and it worked.

We all start out life not knowing how to do things. If we’re lucky, when we need to do something, we can find someone to show us how. But sometimes, we have to come up with a way to do it ourselves. This means thinking of ideas and then trying to decide whether they’re good or not.

This book explores unusual approaches to common tasks, and looks at what would happen to you if you tried them. Figuring out why they would or wouldn’t work can be fun and informative and sometimes lead you to surprising places. Maybe an idea is bad, but figuring out exactly why it’s a bad idea can teach you a lot—and might help you think of a better approach.

And even if you already know the right way to do all these things, it can be helpful to try to look at the world through the eyes of someone who doesn’t. After all, for anything that “everyone knows” by the time they reach adulthood, every day over 10,000 people in the United States alone are learning it for the first time.

That’s why I don’t like making fun of people for admitting they don’t know something or never learned how to do something. Because if you do that, all it does is teach them not to tell you when they’re learning something . . . and you miss out on the fun.

This book may not teach you how to throw a ball, how to ski, or how to move. But I hope you learn something from it. If you do, you’re one of today’s lucky 10,000.

Preorder: Amazon, Barnes & Noble, IndieBound, and Apple Books.

Get social! Or not! Dealer’s choice!

As part of their recent announcement of a new web design system for US government websites, the General Services Administration has also introduced a new typeface called Public Sans.

USWDS 2.0 adds built-in support for custom typefaces, and sometimes you need one that’s simple, neutral, and isn’t Helvetica. Public Sans is an open source, free license typeface (SIL Open Font License 1.1) designed and maintained by USWDS, adapted from Libre Franklin. Just as with our components, we intend Public Sans to be an example of how to design an accessible open source typeface with contributions and feedback from the public — to deliver a useful, neutral, sans serif and continuously improve it.

Always interesting when typefaces are described as “neutral”. I’ve never found that to be the case…

I’m a big fan of tarpits: a network service that intentionally inserts delays in its protocol, slowing down clients by forcing them to wait. This arrests the speed at which a bad actor can attack or probe the host system, and it ties up some of the attacker’s resources that might otherwise be spent attacking another host. When done well, a tarpit imposes more cost on the attacker than the defender.

The Internet is a very hostile place, and anyone who’s ever stood up an Internet-facing IPv4 host has witnessed the immediate and continuous attacks against their server. I’ve maintained such a server for nearly six years now, and more than 99% of my incoming traffic has ill intent. One part of my defenses has been tarpits in various forms. The latest addition is an SSH tarpit I wrote a couple of months ago:

Endlessh: an SSH tarpit

This program opens a socket and pretends to be an SSH server. However, it actually just ties up SSH clients with false promises indefinitely — or at least until the client eventually gives up. After cloning the repository, here’s how you can try it out for yourself (default port 2222):

$ make
$ ./endlessh &
$ ssh -p2222 localhost

Your SSH client will hang there and wait for at least several days before finally giving up. Like a mammoth in the La Brea Tar Pits, it got itself stuck and can’t get itself out. As I write, my Internet-facing SSH tarpit currently has 27 clients trapped in it. A few of these have been connected for weeks. In one particular spike it had 1,378 clients trapped at once, lasting about 20 hours.

My Internet-facing Endlessh server listens on port 22, which is the standard SSH port. I long ago moved my real SSH server off to another port where it sees a whole lot less SSH traffic — essentially none. This makes the logs a whole lot more manageable. And (hopefully) Endlessh convinces attackers not to look around for an SSH server on another port.

How does it work? Endlessh exploits a little paragraph in RFC 4253, the SSH protocol specification. Immediately after the TCP connection is established, and before negotiating the cryptography, both ends send an identification string:

SSH-protoversion-softwareversion SP comments CR LF

The RFC also notes:

The server MAY send other lines of data before sending the version string.

There is no limit on the number of lines, just that these lines must not begin with “SSH-“ since that would be ambiguous with the identification string, and lines must not be longer than 255 characters including CRLF. So Endlessh sends and endless stream of randomly-generated “other lines of data” without ever intending to send a version string. By default it waits 10 seconds between each line. This slows down the protocol, but prevents it from actually timing out.

This means Endlessh need not know anything about cryptography or the vast majority of the SSH protocol. It’s dead simple.

Implementation strategies

Ideally the tarpit’s resource footprint should be as small as possible. It’s just a security tool, and the server does have an actual purpose that doesn’t include being a tarpit. It should tie up the attacker’s resources, not the server’s, and should generally be unnoticeable. (Take note all those who write the awful “security” products I have to tolerate at my day job.)

Even when many clients have been trapped, Endlessh spends more than 99.999% of its time waiting around, doing nothing. It wouldn’t even be accurate to call it I/O-bound. If anything, it’s timer-bound, waiting around before sending off the next line of data. The most precious resource to conserve is memory.

Processes

The most straightforward way to implement something like Endlessh is a fork server: accept a connection, fork, and the child simply alternates between sleep(3) and write(2):

for (;;) {
    ssize_t r;
    char line[256];

    sleep(DELAY);
    generate_line(line);
    r = write(fd, line, strlen(line));
    if (r == -1 && errno != EINTR) {
        exit(0);
    }
}

A process per connection is a lot of overhead when connections are expected to be up hours or even weeks at a time. An attacker who knows about this could exhaust the server’s resources with little effort by opening up lots of connections.

Threads

A better option is, instead of processes, to create a thread per connection. On Linux this is practically the same thing, but it’s still better. However, you still have to allocate a stack for the thread and the kernel will have to spend some resources managing the thread.

Poll

For Endlessh I went for an even more lightweight version: a single-threaded poll(2) server, analogous to stackless green threads. The overhead per connection is about as low as it gets.

Clients that are being delayed are not registered in poll(2). Their only overhead is the socket object in the kernel, and another 78 bytes to track them in Endlessh. Most of those bytes are used only for accurate logging. Only those clients that are overdue for a new line are registered for poll(2).

When clients are waiting, but no clients are overdue, poll(2) is essentially used in place of sleep(3). Though since it still needs to manage the accept server socket, it (almost) never actually waits on nothing.

There’s an option to limit the total number of client connections so that it doesn’t get out of hand. In this case it will stop polling the accept socket until a client disconnects. I probably shouldn’t have bothered with this option and instead relied on ulimit, a feature already provided by the operating system.

I could have used epoll (Linux) or kqueue (BSD), which would be much more efficient than poll(2). The problem with poll(2) is that it’s constantly registering and unregistering Endlessh on each of the overdue sockets each time around the main loop. This is by far the most CPU-intensive part of Endlessh, and it’s all inflicted on the kernel. Most of the time, even with thousands of clients trapped in the tarpit, only a small number of them at polled at once, so I opted for better portability instead.

One consequence of not polling connections that are waiting is that disconnections aren’t noticed in a timely fashion. This makes the logs less accurate than I like, but otherwise it’s pretty harmless. Unforunately even if I wanted to fix this, the poll(2) interface isn’t quite equipped for it anyway.

Raw sockets

With a poll(2) server, the biggest overhead remaining is in the kernel, where it allocates send and receive buffers for each client and manages the proper TCP state. The next step to reducing this overhead is Endlessh opening a raw socket and speaking TCP itself, bypassing most of the operating system’s TCP/IP stack.

Much of the TCP connection state doesn’t matter to Endlessh and doesn’t need to be tracked. For example, it doesn’t care about any data sent by the client, so no receive buffer is needed, and any data that arrives could be dropped on the floor.

Even more, raw sockets would allow for some even nastier tarpit tricks. Despite the long delays between data lines, the kernel itself responds very quickly on the TCP layer and below. ACKs are sent back quickly and so on. An astute attacker could detect that the delay is artificial, imposed above the TCP layer by an application.

If Endlessh worked at the TCP layer, it could tarpit the TCP protocol itself. It could introduce artificial “noise” to the connection that requires packet retransmissions, delay ACKs, etc. It would look a lot more like network problems than a tarpit.

I haven’t taken Endlessh this far, nor do I plan to do so. At the moment attackers either have a hard timeout, so this wouldn’t matter, or they’re pretty dumb and Endlessh already works well enough.

asyncio and other tarpits

Since writing Endless I’ve learned about Python’s asycio, and it’s actually a near perfect fit for this problem. I should have just used it in the first place. The hard part is already implemented within asyncio, and the problem isn’t CPU-bound, so being written in Python doesn’t matter.

Here’s a simplified (no logging, no configuration, etc.) version of Endlessh implemented in about 20 lines of Python 3.7:

import asyncio
import random

async def handler(_reader, writer):
    try:
        while True:
            await asyncio.sleep(10)
            writer.write(b'%x\r\n' % random.randint(0, 2**32))
            await writer.drain()
    except ConnectionResetError:
        pass

async def main():
    server = await asyncio.start_server(handler, '0.0.0.0', 2222)
    async with server:
        await server.serve_forever()

asyncio.run(main())

Since Python coroutines are stackless, the per-connection memory overhead is comparable to the C version. So it seems asycio is perfectly suited for writing tarpits! Here’s an HTTP tarpit to trip up attackers trying to exploit HTTP servers. It slowly sends a random, endless HTTP header:

import asyncio
import random

async def handler(_reader, writer):
    writer.write(b'HTTP/1.1 200 OK\r\n')
    try:
        while True:
            await asyncio.sleep(5)
            header = random.randint(0, 2**32)
            value = random.randint(0, 2**32)
            writer.write(b'X-%x: %x\r\n' % (header, value))
            await writer.drain()
    except ConnectionResetError:
        pass

async def main():
    server = await asyncio.start_server(handler, '0.0.0.0', 8080)
    async with server:
        await server.serve_forever()

asyncio.run(main())

Try it out for yourself. Firefox and Chrome will spin on that server for hours before giving up. I have yet to see curl actually timeout on its own in the default settings (--max-time/-m does work correctly, though).

Parting exercise for the reader: Using the examples above as a starting point, implement an SMTP tarpit using asyncio. Bonus points for using TLS connections and testing it against real spammers.

Leaving Neverland is a two-part documentary exploring the separate but parallel experiences of two young boys, James Safechuck, at age ten, and Wade Robson, at age seven, both of whom were befriended by Michael Jackson. Through gut-wrenching interviews with Safechuck, now 37, and Robson, now 41, as well as their mothers, wives and siblings, the film crafts a portrait of sustained abuse, exploring the complicated feelings that led both men to confront their experiences after both had a young son of his own.

As this quick timeline of abuse allegations against Jackson notes, both Safechuck and Robson previously denied that Jackson had abused them.

Robson, by this point a choreographer for stars like Britney Spears, testified that he had spent the night at Neverland more than 20 times but that Jackson had never molested him or taken a shower with him.

James Safechuck, who had met Jackson as a young boy in the 1980s when he was cast in a Pepsi commercial, also denied publicly that he had been abused, although he was not called to testify.

David Ehrlich saw the film at Sundance and was completely convinced by the stories of the two men.

It may not be much of a secret that Michael Jackson acted inappropriately with a number of young boys, but there’s no way to prepare yourself for the sickening forensic details presented in Dan Reed’s four-hour exposé. It’s one thing to be vaguely aware of the various allegations that were made against the King of Pop; the asterisks that will always be next to the late mega-star’s name. It’s quite another to hear the horrifyingly lucid testimony that stretches across the entire duration of “Leaving Neverland,” as two of Jackson’s most repeat victims bravely lay bare how a universal icon seduced them away from their realities, splintered their families beyond all recognition, and leveraged their love for him into a disturbing litany of sexual acts.

The eloquent and straightforward “Leaving Neverland” was made for no other reason than to give shape to a nebulous cloud of rumors, many of which were floated in public before they were silenced behind settlements, and none of which a jury was able to prove beyond a reasonable doubt. In the wake of Reed’s film and the shattering interview footage that it exists to share with us, there’s no longer a reasonable doubt. There’s no longer any doubt at all. Not only do the documentary’s two main subjects perfectly corroborate their separate accounts in all of the most tragic of ways, but they do so with a degree of vulnerability that denies any room for skepticism.

Other stars who previously had private or ignored abuse allegations leveled against them — Kevin Spacey, Bill Cosby, R. Kelly, Woody Allen, Louis CK — have been judged more harshly and their accusers have taken more seriously in recent years, and it’ll be interesting to see what happens with Jackson after the documentary airs.

Randall Munroe, proprietor of the excellent XKCD and author of What If? and Thing Explainer, is coming out with a new book in a few months called How To: Absurd Scientific Advice for Common Real-World Problems.

Bestselling author and cartoonist Randall Munroe explains how to predict the weather by analyzing the pixels of your Facebook photos. He teaches you how to tell if you’re a baby boomer or a 90’s kid by measuring the radioactivity of your teeth. He offers tips for taking a selfie with a telescope, crossing a river by boiling it, and getting to your appointments on time by destroying the Moon. And if you want to get rid of the book once you’re done with it, he walks you through your options for proper disposal, including dissolving it in the ocean, converting it to a vapor, using tectonic plates to subduct it into the Earth’s mantle, or launching it into the Sun.

Instant pre-order.

Parent Memes

Follow us on:

 

• Source control, project home, issue tracking, and everything else that comes with GitLab.
• Content and images (metadata) for Google Play Store listing managed in source control.
• Automatic signing, version numbers, and changelog.
• Automatic publishing to internal distribution channel in Google Play Store.
• Manual promotion through alpha, beta, and production channels.
• Containerized build environment, available in GitLab's container registry.

If you'd like to jump ahead and see the finished product, you can take a look at the already-completed Gitter for Android .gitlab-ci.yml, build.gradle, Dockerfile, and fastlane configuration.

Configuring fastlane

We'll begin first by setting up fastlane in our project, make a couple key changes to our Gradle configuration, and then wrap everything up in a GitLab pipeline.

fastlane has pretty good documentation to get you started, and if you run into platform-specific trouble it's the first place to check, but to get under way you really just need to complete a few straightforward steps.

Initializing your project

First up, you need to get fastlane installed locally and initialize your product. We're using the Ruby fastlane gem so you'll need Ruby on your system for this to work. You can read about other install options in the fastlane documentation.

source "https://rubygems.org"

gem "fastlane"

Once your Gemfile is updated, you can run bundle update to update/generate your Gemfile.lock. From this point you can run fastlane by typing bundle exec fastlane. Later, you'll see that in CI we use bundle install ... to ensure the command runs within the context of our project environment.

Now that we have fastlane ready to run, we just need to initialize our repo with our configuration. Run bundle exec fastlane init from within your project directory, answer a few questions, and fastlane will create a new ./fastlane directory containing its configuration.

Setting up supply

supply is a feature built into fastlane which will help you manage screenshots, descriptions, and other localized metadata/assets for publishing to the Google Play Store.

Please refer to these detailed instructions for collecting the credentials necessary to run supply.

Once you've set this up, simply run bundle exec fastlane supply init and all your current metadata will be downloaded from your store listing and saved in fastlane/metadata/android. From this point you're able to manage all of your store content as-code; when we publish a new version to the store later, the versions of content checked into your source repo will be used to populate the entry.

Appfile

The ./fastlane/Appfile is pretty straightforward, and contains basic configuration you chose when you initialized your project. Later we'll see how to inject the json_key_file in your CI pipeline at runtime.

./fastlane/Appfile

json_key_file("~/google_play_api_key.json") # Path to the json secret file - Follow https://docs.fastlane.tools/actions/supply/#setup to get one
package_name("im.gitter.gitter") # e.g. com.krausefx.app

Fastfile

The ./fastlane/Fastfile is more interesting, and contains the first changes you'll see that we made for Gitter vs. the default one created when you run bundle exec fastlane init.

The first section contains our definitions for how we want to run builds and tests. As you can see, this is pretty straightforward and builds right on top of your already set up Gradle tasks.

./fastlane/Fastfile

default_platform(:android)

platform :android do

  desc "Builds the debug code"
  lane :buildDebug do
    gradle(task: "assembleDebug")
  end

  desc "Builds the release code"
  lane :buildRelease do
    gradle(task: "assembleRelease")
  end

  desc "Runs all the tests"
  lane :test do
    gradle(task: "test")
  end

...

Creating Gradle tasks that publish/promote builds can be complicated and error prone, but fastlane makes this much easier by giving you pre-built commands (called Actions) that let you perform complex tasks with just a few simple actions.

In our example, we've set up a workflow where a new build can be published to the internal track and then optionally promoted through alpha, beta, and ultimately production. We initially had a new build for each track but it's safer to have the same/known build go through the whole process.

...

  desc "Submit a new Internal Build to Play Store"
  lane :internal do
    upload_to_play_store(track: 'internal', apk: 'app/build/outputs/apk/release/app-release.apk')
  end

  desc "Promote Internal to Alpha"
  lane :promote_internal_to_alpha do
    upload_to_play_store(track: 'internal', track_promote_to: 'alpha')
  end

  desc "Promote Alpha to Beta"
  lane :promote_alpha_to_beta do
    upload_to_play_store(track: 'alpha', track_promote_to: 'beta')
  end

  desc "Promote Beta to Production"
  lane :promote_beta_to_production do
    upload_to_play_store(track: 'beta', track_promote_to: 'production')
  end
end

An important note is that we've only scratched the surface of the kinds of actions that fastlane can automate. You can read more about available actions here, and it's even possible to create your own.

Gradle configuration

We also made a couple of key changes to our basic Gradle configuration to make publishing easier. Nothing major here, but it does help us make things run a little more smoothly.

Secret properties

The first changed section gathers the secret variables to be used for signing. These are either loaded via configuration file, or gathered from environment variables in the case of CI.

app/build.gradle

// Try reading secrets from file
def secretsPropertiesFile = rootProject.file("secrets.properties")
def secretProperties = new Properties()

if (secretsPropertiesFile.exists()) {
    secretProperties.load(new FileInputStream(secretsPropertiesFile))
}
// Otherwise read from environment variables, this happens in CI
else {
    secretProperties.setProperty("oauth_client_id", "\"${System.getenv('oauth_client_id')}\"")
    secretProperties.setProperty("oauth_client_secret", "\"${System.getenv('oauth_client_secret')}\"")
    secretProperties.setProperty("oauth_redirect_uri", "\"${System.getenv('oauth_redirect_uri')}\"")
    secretProperties.setProperty("google_project_id", "\"${System.getenv('google_project_id') ?: "null"}\"")
    secretProperties.setProperty("signing_keystore_password", "${System.getenv('signing_keystore_password')}")
    secretProperties.setProperty("signing_key_password", "${System.getenv('signing_key_password')}")
    secretProperties.setProperty("signing_key_alias", "${System.getenv('signing_key_alias')}")
}

Automatic versioning

We also set up automatic versioning using environment variables VERSION_CODE, VERSION_SHA, which we will set up later in CI (locally they will just be null which is fine). Because each build's versionCode that you submit to the Google Play Store needs to be higher than the last, this makes it simple to deal with.

app/build.gradle

android {
    defaultConfig {
        applicationId "im.gitter.gitter"
        minSdkVersion 19
        targetSdkVersion 26
        versionCode Integer.valueOf(System.env.VERSION_CODE ?: 0)
        // Manually bump the semver version part of the string as necessary
        versionName "3.2.0-${System.env.VERSION_SHA}"

Signing configuration

Finally, we inject the signing configuration which will automatically be used by Gradle to sign the release build. Depending on your configuration, you may already be doing this. We only worry about signing in the release build that would potentially be published to the Google Play Store.

When using App Signing by Google Play, you will use two keys: the app signing key and the upload key. You keep the upload key and use it to sign your app for upload to the Google Play Store.

https://developer.android.com/studio/publish/app-signing#google-play-app-signing

IMPORTANT: Google will not re-sign any of your existing or new APKs that are signed with the app signing key. This enables you to start testing your app bundle in the internal test, alpha, or beta tracks while you continue to release your existing APK in production without Google Play changing it.

https://play.google.com/apps/publish/?account=xxx#KeyManagementPlace:p=im.gitter.gitter&appid=xxx

app/build.gradle

    signingConfigs {
        release {
            // You need to specify either an absolute path or include the
            // keystore file in the same directory as the build.gradle file.
            storeFile file("../android-signing-keystore.jks")
            storePassword "${secretProperties['signing_keystore_password']}"
            keyAlias "${secretProperties['signing_key_alias']}"
            keyPassword "${secretProperties['signing_key_password']}"
        }
    }
    buildTypes {
        release {
            minifyEnabled false
            testCoverageEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }
}

Setting up the Docker build environment

We are building a Docker image to be used as a repeatable, consistent build environment which will speed things up because it will already have the dependencies downloaded and installed. We're just fetching a few prerequisites, installing the Android SDK, and then grabbing fastlane.

Dockerfile

FROM openjdk:8-jdk

# Just matched `app/build.gradle`
ENV ANDROID_COMPILE_SDK "26"
# Just matched `app/build.gradle`
ENV ANDROID_BUILD_TOOLS "28.0.3"
# Version from https://developer.android.com/studio/releases/sdk-tools
ENV ANDROID_SDK_TOOLS "24.4.1"

ENV ANDROID_HOME /android-sdk-linux
ENV PATH="${PATH}:/android-sdk-linux/platform-tools/"

# install OS packages
RUN apt-get --quiet update --yes
RUN apt-get --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 build-essential ruby ruby-dev
# We use this for xxd hex->binary
RUN apt-get --quiet install --yes vim-common
# install Android SDK
RUN wget --quiet --output-document=android-sdk.tgz https://dl.google.com/android/android-sdk_r${ANDROID_SDK_TOOLS}-linux.tgz
RUN tar --extract --gzip --file=android-sdk.tgz
RUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter android-${ANDROID_COMPILE_SDK}
RUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter platform-tools
RUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter build-tools-${ANDROID_BUILD_TOOLS}
RUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-android-m2repository
RUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-google_play_services
RUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-m2repository
# install Fastlane
COPY Gemfile.lock .
COPY Gemfile .
RUN gem install bundle
RUN bundle install

Setting up GitLab

With our build environment ready, let's set up our .gitlab-ci.yml to tie it all together in a CI/CD pipeline.

Stages

The first thing we do is define the stages that we're going to use. We'll set up our build environment, do our debug and release builds, run our tests, deploy to internal, and then promote through alpha, beta, and production. You can see that, apart from environment, these map to the lanes we set up in our Fastfile.

stages:
  - environment
  - build
  - test
  - internal
  - alpha
  - beta
  - production

Build environment update

Next up we're going to update our build environment, if needed. If you're not familiar with .gitlab-ci.yml it may look like there's a lot going on here, but we'll take it one step at a time. The very first thing we do is set up an .updateContainerJob yaml template which can be used to capture shared configuration for other steps that want to use it. In this case, it will be used by the subsequent updateContainer and ensureContainer jobs.

.updateContainerJob template

In this case, since we're dealing with Docker in Docker (dind), we are running some scripts which log into the local GitLab container registry, fetch the latest image to be used as a layer cache reference, build a new image, and finally push the new version to the registry.

.updateContainerJob:
  image: docker:stable
  stage: environment
  services:
    - docker:dind
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG || true
    - docker build --cache-from $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

updateContainer job

The first job that inherits .updateContainerJob, updateContainer, only runs if the Dockerfile was updated and will run through the template steps described above.

updateContainer:
  extends: .updateContainerJob
  only:
    changes:
      - Dockerfile

ensureContainer job

Because the first pipeline on a branch can fail, the only: changes: Dockerfile syntax won't trigger for a subsequent pipeline after you fix things. This can leave your branch without a Docker image to use. So the ensureContainer job will look for an existing image and only build one if it doesn't exist. The one downside to this is that both of these jobs will run at the same time if it is a new branch.

Ideally, we could just use $CI_REGISTRY_IMAGE:master as a fallback when $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG isn't found but there isn't any syntax for this.

ensureContainer:
  extends: .updateContainerJob
  allow_failure: true
  before_script:
    - "mkdir -p ~/.docker && echo '{\"experimental\": \"enabled\"}' > ~/.docker/config.json"
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    # Skip update container `script` if the container already exists
    # via https://gitlab.com/gitlab-org/gitlab-ce/issues/26866#note_97609397 -> https://stackoverflow.com/a/52077071/796832
    - docker manifest inspect $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG > /dev/null && exit || true

Build and test

With our build environment ready, we're ready to build our debug and release targets. Similar to above, we use a template to set up repeated steps within our build jobs, avoiding duplication. Within this section, the first thing we do is set the image to the build environment container image we built in the previous step.

.build_job template

.build_job:
  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  stage: build

...

Next up is a step that's specific to Gitter, but if you use shared assets between a iOS and Android build you might consider doing something similar. What we're doing here is grabbing the latest mobile artifacts built by the web application pipeline and placing them in the appropriate location.

  before_script:
    - wget --output-document=artifacts.zip --quiet "https://gitlab.com/gitlab-org/gitter/webapp/-/jobs/artifacts/master/download?job=mobile-asset-build"
    - unzip artifacts.zip
    - mkdir -p app/src/main/assets/www
    - mv output/android/www/* app/src/main/assets/www/

Next, we use project-level variables containing a binary (hex) dump of our signing keystore file and convert it back to a binary file. This allows us to inject the file into the build at runtime instead of checking it into source control, a potential security concern. To get the signing_jks_file_hex variable hex value, we use this binary -> hex command, xxd -p gitter-android-app.jks

    # We store this binary file in a variable as hex with this command, `xxd -p gitter-android-app.jks`
    # Then we convert the hex back to a binary file
    - echo "$signing_jks_file_hex" | xxd -r -p - > android-signing-keystore.jks

Here we're setting the version at runtime – these environment variables will be used by the Gradle build as implemented above. Because $CI_PIPELINE_IID increments on each pipeline, we can guarantee our versionCode is always higher than the last and be able to publish to the Google Play Store.

    # We add 100 to get this high enough above current versionCodes that are published
    - "export VERSION_CODE=$((100 + $CI_PIPELINE_IID)) && echo $VERSION_CODE"
    - "export VERSION_SHA=`echo ${CI_COMMIT_SHORT_SHA}` && echo $VERSION_SHA"

Next, we automatically generate a changelog to include by copying whatever you have in CURRENT_VERSION.txt to the current <versionCode>.text. You can update CURRENT_VERSION.txt as necessary. I won't dive into the the details of the MR creation script here since it's somewhat specific to Gitter, but if you're interested in how something like this might work check out the create-changlog-mr.sh script.

    # Make the changelog
    - cp ./fastlane/metadata/android/en-GB/changelogs/CURRENT_VERSION.txt "./fastlane/metadata/android/en-GB/changelogs/$VERSION_CODE.txt"
    # We allow the remote push and MR creation to fail because the other job could create it
    # and it's not strictly necessary (we just need the file locally for the CI build)
    - ./ci-scripts/create-changlog-mr.sh || true
    # Because we allow the MR creation to fail, just make sure we are back in the right repo state
    - git checkout "$CI_COMMIT_SHA"

Just a couple of final items: First, whenever a build job is done, we remove the jks file just to be sure it doesn't get saved to artifacts, and second we set up the artifact directory from where the output of the build (.apk) will be saved.

  after_script:
    - rm android-signing-keystore.jks || true
  artifacts:
    paths:
    - app/build/outputs

buildDebug and buildRelease jobs

Most of the complexity here was set up in the template, so as you can see our buildDebug and buildRelease job definitions are very clear. Both just call the appropriate fastlane task (which, if you remember, then calls the appropriate Gradle task). The buildRelease output is associated with the production environment so we can define an extra production-scoped set of project-level variables which are different from our testing variables.

Since we set up code signing in the Gradle config (build.gradle) earlier, we can be confident here that our release builds are appropriately signed and ready for publishing.

buildDebug:
  extends: .build_job
  script:
    - bundle exec fastlane buildDebug

buildRelease:
  extends: .build_job
  script:
    - bundle exec fastlane buildRelease
  environment:
    name: production

Testing is really just another instance of the same thing, but instead of calling one of the build lanes we call the test lane. Note that we are using a dependency from the buildDebug job to ensure we don't need to rebuild anything.

testDebug:
  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  stage: test
  dependencies:
    - buildDebug
  script:
    - bundle exec fastlane test

Publish

Now that our code is being built, we're ready to publish to the Google Play Store. We only publish to the internal testing track and promote this same build to the rest of the tracks.

This is achieved through the fastlane integration, using a pre-built action to handle the job. In this case we are using a dependency on the buildRelease job, and creating a local copy of the Google API JSON keyfile (again stored in a project-level variable instead of checking it into source control.) We have this job (and all subsequent jobs) set to run only on manual action so we have full human control/intervention from this point forward. If you prefer to continuously deliver to your internal track you'd simply need to remove the when: manual entry and you'd have achieved your goal.

If you're like me, this may seem too easy to work. With everything we've configured in GitLab and fastlane to this point, it's really this simple!

publishInternal:
  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  stage: internal
  dependencies:
    - buildRelease
  when: manual
  before_script:
    - echo $google_play_service_account_api_key_json > ~/google_play_api_key.json
  after_script:
    - rm ~/google_play_api_key.json
  script:
    - bundle exec fastlane internal

Promote

As indicated earlier, promotion through alpha, beta, and production are all manual jobs. If internal testing is good, it can be promoted one step forward in sequence all the way through to production using these manual jobs.

If you're with me to this point, there's really nothing new here and this really highlights the power of GitLab with fastlane. We have a .promote_job template job which creates the local Google API JSON key file and the promote jobs themselves are basically identical.

.promote_job:
  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  when: manual
  dependencies: []
  only:
    - master
  before_script:
    - echo $google_play_service_account_api_key_json > ~/google_play_api_key.json
  after_script:
    - rm ~/google_play_api_key.json

promoteAlpha:
  extends: .promote_job
  stage: alpha
  script:
    - bundle exec fastlane promote_internal_to_alpha

promoteBeta:
  extends: .promote_job
  stage: beta
  script:
    - bundle exec fastlane promote_alpha_to_beta

promoteProduction:
  extends: .promote_job
  stage: production
  script:
    - bundle exec fastlane promote_beta_to_production

Note that we're only allowing production promotion from the master branch, instead of from any branch. This is to ensure that the production build uses the separate set of production environment variables which only happens for the buildRelease job. We also have these variables set as protected so we can enforce that they are only used on the master branch which is protected.

Variables

The last step is to make sure you set up the project-level variables we used throughout the configuration above:

• google_play_service_account_api_key_json: see https://docs.fastlane.tools/getting-started/android/setup/#collect-your-google-credentials
• oauth_client_id
• oauth_client_id, protected, production environment
• oauth_client_secret
• oauth_client_secret, protected, production environment
• oauth_redirect_uri
• oauth_redirect_uri, protected, production environment
• signing_jks_file_hex: xxd -p gitter-android-app.jks
• signing_key_alias
• signing_key_password
• signing_keystore_password

If you are using the same create-changlog-mr.sh script as us,

• deploy_key_android_repo: see https://docs.gitlab.com/ee/user/project/deploy_tokens/
• gitlab_api_access_token: see https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html (we use a bot user)

What's next

Using this configuration we've got Gitter for Android building, signing, deploying to our internal track, and publishing to production as frequently as we like. Next up will be to do the same for iOS, so watch this space for our next post!

Photo by Patrick Tomasso on Unsplash