Svelte Basics

Styling React Components

These are some of my dreams for a great design system. 



The best design system would be the one that was already made, cost nothing additional, and fit my needs perfectly. But in the case of a company making a custom design system that meets their specific needs, here are some value targets that I think would be worth pointing toward. Of course, some are quite aspirational, even pie. in. the. sky.

1. Have a real design standard. Flows from design group. Designers committed to it. Designs are made so-as to follow it.
1. A design language. A ubiquitous language. Well defined. Consistently used. Increases efficiency and effectiveness of conversations between design and development.
1. Product designers and developers are made more co-equal partners — in DS design and dev and in daily frontend work. Largely enabled by the transparency of a shared standard. Help each other push toward that standard.
1. It's authoritative. Singular. Found in one accessible location. Up to date. True, and reliable.
1. It's prepared for evolution. Fits the needs of a changing business and product. Never becomes the ball and chain that simply slows us down. Or the design police. Or the thing that always says "no" to change.
1. It's delightful. Hopefully fun. Something we can be proud to work on and show to our users.
1. Uses 3rd-party assistance. Doesn't suffer from "not made here" syndrome. Gains efficiency, but keeps user-facing company personality.
1. Open source. Work showcase. Frontend recruiting tool
1. WCAG 2.1 AA compatible
1. Server-renderable
1. Used as native modules. Outside of app bundles. CDN-served. Cached. Shared network resource
1. Easy upgrades. Avoids breaking changes. Backwards compatibility. Slick versioning scheme.
1. Long term vision. Practical first steps. Always eats down technical debt. Never overwhelmed.
1. Clearly defines what is out of scope. Doesn't become the dumping ground for anything potentially reusable or actually reused. Clear product definition. Other places for other things.
1. Framework agnostic. Or universally compatible. Web native.
1. No duplication in design assets and code implementation. One begets the other. Always in sync

My Design System Dreams

Here's a method to test a distributed lock via a dynamodb table in pytest.



## Why a distributed lock

If you can avoid locking, do it. It's probably hard to get right. The lock in this example is rudimentary.

If you have a shared resource where control of it is important to its processing, you might want a lock around that resource so only one operator can touch it at a time. For example, you want writes to be made to a shared resource one at a time so they don't conflict.

## Why DynamoDb

I chose Dynamodb for a place to store a lock because of a few factors. I'm in AWS already. I'm in AWS Lambdas. It was the simplest shared store that occurred to me. It has a couple nice properties including conditional writes and some testing utilities around it.

## The lock table

The lock table is very simple. It's a single-attribute table, where that attribute represents the resource we're locking on, `ResourceId`. Here's the CloudFormation template used by SAM:

```yaml
# template.yaml

# allow aws to write the table
MyLambdaFunction:
  # ...
  Properties:
    - DynamoDBCrudPolicy
        TableName: !Ref ResourceLockTable

# the table itself
ResourceLockTable:
  Type: AWS::DynamoDB::Table
  DeletionPolicy: Delete
  Properties:
    TableName: resource_locks
    AttributeDefinitions:
      - AttributeName: resource_id
        AttributeType: N
    KeySchema:
      - AttributeName: resource_id
        KeyType: HASH
    BillingMode: PAY_PER_REQUEST
```

## Acquiring the lock

To acquire the lock, we write an item to the table. The lock is per `resource_id`. There's a `ConditionExpression` on our `put_item` that allows the put operation to fail if the condition is not met. We want to fail is the resource is already locked, signified by the presence of that `resource_id` value already in the attribute. In the case of lock acquisition, we'll return true. If failed, we'll return false

```python
# mutex.py
import boto3


def _create_client():
  return boto3.client("dynamodb")

def _request_lock(resource_id, client=_create_client()):
  try:
    client.put_item(
      TableName='resource_locks',
      Item={
          "resource_id": {"N": resource_id},
      },
      ConditionExpression= "resource_id <> :resource_id",
      ExpressionAttributeValues= {
          ":resource_id" : { "N": resource_id },
      }
    )
    return True
  catch client.exceptions.ConditionalCheckFailedException:
    return False
```

## Testing unique locks

For testing, we'll use pytest.  We'll create a unit test that allows us to see if our `put_item` implementation will create unique locks as we have designed. We'll use the `moto` library to create a local dynamodb table. For this setup, install:

```
pipenv install pytest pytest-describe moto --dev
```

We'll set up the table as a fixture that we can use in our test. We have to re-specify it separate from our `template.yaml`. The fixture has a setup and a teardown. Just to be cautious, we'll also setup a fixture that replaces any environmental variables that AWS libraries use for real access:

```python
#test_mutex.py

import boto3
from moto import mock_dynamodb2
import os
import pytest

from . import mutex


@pytest.fixture(scope='module')
def aws_credentials():
  os.environ["AWS_ACCESS_KEY_ID"] = 'testing'
  os.environ["AWS_SECRET_ACCESS_KEY"] = 'testing'
  os.environ["AWS_SECURITY_TOKEN"] = 'testing'
  os.environ["AWS_SESSION_TOKEN"] = 'testing'

@pytest.fixture(scope='module')
def dynamodb_client(aws_credentials):
  with mock_dynamodb2():
    client = boto3.client('dynamodb')
    yield client

@pytest.fixture()
def setup_lock_table(dynamodb_client):
  dynamodb_client.create_table(
    TableName='resource_locks',
    KeySchema=[
      {
        'AttributeName': 'resource_id',
        'KeyType': 'HASH'
      },
    ],
    AttributeDefinitions=[
      {
        'AttributeName': 'resource_id',
        'AttributeType': 'N'
      },
    ],
    ProvisionedThroughput={
      'ReadCapacityUnits': 1,
      'WriteCapacityUnits': 1
    }
  )

  yield "setup_lock_table"

  dynamodb_client.delete_table(
      TableName='resource_locks',
  )
  dynamodb_client=None

def describe_request_lock():

  def test_when_open(setup_lock_table, dynamodb_client):
    resource_id = "12345"
    assert mutext._request_lock(resource_id, {}, client=dynamodb_client)

    lock_row = dynamodb_client.get_item(TableName="resource_locks", Key={ "resource_id": { "N": resource_id } })["Item"]
    assert lock_row == { "resource_id": { "N": resource_id } }

  def test_when_locked(setup_lock_table, dynamodb_client):
    resource_id = "23456"
    assert mutex._request_lock(resource_id, {}, client=dynamodb_client)
    assert not mutex._request_lock(resource_id, {}, client=dynamodb_client)
```

## There's more

That's what's required to get the `put_item` tested on a lock table in DynamoDb. But there is more to consider: What happens if the lock is already held? What if the lock owner never releases it? Polling and lock TTLs are potential answers and good subjects for another article.

How do you create and test distributed locks in an environment like AWS Lambda or DynamoDb?

A method to test a distributed lock via a dynamodb table in pytest

Test a Distributed Lock in Dynamodb

Here's a method to download photos from your iPhone on Arch Linux. An unholy combination? Yeah, probably.



## tl;dr

```
sudo pacman -S libimobiledevice # needed protocols to connect
yay -S ifuse # needed to mount
systemctl start usbmuxd.service # ensure service running
idevicepair pair # pair phone
mkdir /mnt/iphone # place to mount
sudo ifuse -o allow_other /mnt/iphone # mount phone
ls /mnt/iphone # go explore
```

## Communicate with the iPhone

First, you need a library to help with the protocols to communicate with the iPhone. `libimobiledevice` will do that. Install it with:

```
sudo pacman -S libimobiledevice
```

Next, you want to make sure that the service to access USB devices is running. To do that, run:

```
systemctl status usbmuxd.service
```

If it's not active, you can start it

```
systemctl start usbmuxd.service
```

## Query USB devices

You'll want to make sure you connect your iPhone to the computer with a USB cable. Make sure that you unlock the phone and "Trust this computer" when the phone brings up that dialog. Sometimes I have to plug in and unplug several times before I get this dialog.

Optionally, you can also do some detection of USB devices separate from the pairing (next step). A little lib called `usbutils` can help:

```
sudo pacman -S usbutils
```

Then you can run this to get a listing of USB devices (similar to `lsblk`):

```
lsusb
```

That will return a list of devices, including something like this iPhone item:

```
...
Bus 001 Device 005: ID 05ac:12a8 Apple, Inc. iPhone 5/5C/5S/6/SE
...
```

From `libimobiledevice`, you can also query about iPhones specifically:

```
ideviceinfo
```

## Pair the iPhone

Now to be able to talk to the iPhone from the computer, you need to pair it with:

```
idevicepair pair
```

If all goes well, you'll see something like:

```
SUCCESS: Paired with device 00008020-001A44E40E99002E
```

## Mounting the filesystem

To be able to browse and download files from the iPhone's filesystem, you need to mount it.

To allow mounting iOS devices, install this AUR package:

```
yay -S ifuse
```

Then create a place you want to mount it. For instance:

```
mkdir -p /mnt/iphone
```

The you can run this command:

```
sudo ifuse -o allow_other /mnt/iphone
```

Now if I was to navigate to `/mnt/iphone`, I might see something like:

```
/mnt/iphone🔒 ✦ ➜ ls -1
Books
CloudAssets
DCIM
Downloads
iTunes_Control
MediaAnalysis
PhotoData
Photos
Podcasts
Purchases
Recordings
```

## Copy files

Now that the filesystem is mounted, one could copy files off of the iPhone with something like:

```
cp -r /mnt/iphone/DCIM ~/Downloads
```

## Clean up

To clean up and reverse the process, unpair:

```
idevicepair unpair
```

And unmount:

```
sudo umount /mnt/iphone
```

What better ways are there to connect to an iPhone from Arch Linux?

Access your iPhone photos from Arch Linux

Connect iPhone to Arch Linux

Live in i3, live in the terminal. No GUI for changing display properties. So, here's a CLI command to set a new screen resolution.



## tl;dr

In `xrandr` lingo, a "mode" is approximately a "resolution" and an "output" is a "monitor".

```
xrandr # list available outputs and modes
cvt 3840 2160 60 # calculate mode line (for 3840x2160)
xrandr --newmode <modeline> # create new mode
xrandr --addmode <output> 3840x2160_60.00 # associate mode with output
xrandr --output <output> --mode 3840x2160_60.00 # set output use mode
```

Use the `man` pages for extra help.

## Discover screen capability

First, discover what displays and resolutions are available to you. Do that with:

```
xrandr
```

You'll get an output something like:

```
eDP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   2560x1440    165.00*+  40.00 +
   1920x1440     85.00    75.00    60.00
   ...
```

Look for preconnected displays that are already ready to display things. Connecting displays can be a chore in itself, depending on circumstances. We won't cover that here.

Note the output name -- in this case `eDP-1`. 

## Unlisted resolutions

You may not have the desired mode listed for the output. But the output may support another mode. `xrandr` may tell you about the min or max resolutions.

Once you know your resolution, xorg wants you to specify it as a new mode. To get to that step, you need a modeline to feed to it. To get the modeline, use the `cvt` command. Feed it `cvt <horz px> <vert px> <refresh rate>`.

For, `cvt 3840 2160 60` on this monitor, I get:

```
# 3840x2160 59.98 Hz (CVT 8.29M9) hsync: 134.18 kHz; pclk: 712.75 MHz
Modeline "3840x2160_60.00"  712.75  3840 4160 4576 5312  2160 2163 2168 2237 -hsync +vsync
```

The text after "Modeline" is what you need for the next step.

To get that mode added to the output, it requires a two-stepper:

```
xrandr --newmode "3840x2160_60.00"  712.75  3840 4160 4576 5312  2160 2163 2168 2237 -hsync +vsync
xrandr --addmode eDP-1 3840x2160_60.00
```

This creates a new mode called "3840x2160_60.00" and associates it with `eDP-1` output.

## Set the resolution

Now that you have the mode set up and associated with the output, use `xrandr` to set the output to use that mode.

```
xrandr --output eDP-1 --mode 3840x2160_60.00
```

If it works, your monitor will immediately switch into the requested resolution. Say hello to tiny 4k terminal text.

## Persist resolution choice

Now if you want to persist this change so you don't have to type the `xrandr` commands in the next time you reboot, then add the `--newmode`, `--addmode` and `--output` commands to `~/.xprofile`.

Set the screen resolution from the terminal in i3

Skill up with a sweet course

Find spicey tips in tech

My Design System Dreams

Test a Distributed Lock in Dynamodb

Connect iPhone to Arch Linux

Set Screen Resolution in i3 with Xrandr