env_logger

env_logger is a simple logger that can be configured via environment variables, for use with the logging facade exposed by the log crate.

Despite having env in its name, env_logger can also be configured by other means besides environment variables. See the examples in the source repository for more approaches.

By default, env_logger writes logs to stderr, but can be configured to instead write them to stdout.

log

log is a lightweight logging facade.

The log crate provides a single logging API that abstracts over the actual logging implementation. Libraries can use the logging API provided by this crate, and the consumer of those libraries can choose the logging implementation that is most suitable for its use case.

If no logging implementation is selected, the facade falls back to a “noop” implementation that ignores all log messages. The overhead in this case is very small - just an integer load, comparison and jump.

A log request consists of a target, a level, and a body. A target is a string which defaults to the module path of the location of the log request, though that default may be overridden. Logger implementations typically use the target to filter requests based on some user configuration.

log4rs

log4rs is a highly configurable logging framework modeled after Java’s Logback and log4j libraries.

uuid

uuid Provides support for Universally Unique Identifiers (UUIDs). A UUID is a unique 128-bit number, stored as 16 octets. UUIDs are used to assign unique identifiers to entities without requiring a central allocating authority.

Rocket - Getting Started

Rocket is a web framework for Rust. If you’d like, you can think of Rocket as being a more flexible, friendly medley of Rails - https://rubyonrails.org/, Flask - https://palletsprojects.com/p/flask/, Bottle - https://bottlepy.org/docs/dev/index.html, and Yesod - https://www.yesodweb.com/. We prefer to think of Rocket as something new. Rocket aims to be fast, easy, and flexible while offering guaranteed safety and security where it can. Importantly, Rocket also aims to be fun, and it accomplishes this by ensuring that you write as little code as needed to accomplish your task.

Let’s create and run our first Rocket application. We’ll ensure we have a compatible Rust toolchain installed, create a new Cargo project that depends on Rocket, and then run the application.

no matching host key type found. Their offer: ssh-rsa,ssh-dss

You may see an error no matching host key type found. Their offer: ssh-rsa,ssh-dss when us git clone a remote project / repository with SSH.

1
2
3

$ git clone ssh://git@<Your Git Host>:<Your Git Port>/<Your Group>/<Your Project>.git
Unable to negotiate with <Your Git Host> port <Your Git Port>: no matching host key type found. Their offer: ssh-rsa,ssh-dss
fatal: Could not read from remote repository.

DST Root CA X3 Expiration and use ISRG Root X1

Update September 30, 2021 As planned, the DST Root CA X3 cross-sign has expired, and we’re now using our own ISRG Root X1 for trust on almost all devices. For more details about the plan, keep reading! We have also updated our Production Chain Changes thread on our community forum - our team and community are here and ready to help with any questions you may have about this expiration.

On September 30 2021, there will be a small change in how older browsers and devices trust Let’s Encrypt certificates. If you run a typical website, you won’t notice a difference - the vast majority of your visitors will still accept your Let’s Encrypt certificate. If you provide an API or have to support IoT devices, you might have to pay a little more attention to the change.

MobX React integration

While MobX works independently from React, they are most commonly used together. In The gist of MobX you have already seen the most important part of this integration: the observer HoC that you can wrap around a React component.

Installation

1
2
3
4

$ npm install -s mobx-react-lite

# Or 
# $ npm install -s mobx-react

Usage

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
26
27
28
29
30

// src/main.js

import React from "react"
import ReactDOM from "react-dom"
import { makeAutoObservable } from "mobx"
import { observer } from "mobx-react-lite"

class Timer {
    secondsPassed = 0

    constructor() {
        makeAutoObservable(this)
    }

    increaseTimer() {
        this.secondsPassed += 1
    }
}

const myTimer = new Timer()

// A function component wrapped with `observer` will react
// to any future change in an observable it used before.
const TimerView = observer(({ timer } : { timer: Timer }) => <span>Seconds passed: {timer.secondsPassed}</span>)

ReactDOM.render(<TimerView timer={myTimer} />, document.body)

setInterval(() => {
    myTimer.increaseTimer()
}, 1000)

Hint: you can play with the above example yourself on CodeSandbox - https://codesandbox.io/s/minimal-observer-p9ti4?file=/src/index.tsx.

The observer HoC automatically subscribes React components to any observables that are used during rendering. As a result, components will automatically re-render when relevant observables change. It also makes sure that components don’t re-render when there are no relevant changes. So, observables that are accessible by the component, but not actually read, won’t ever cause a re-render.

In practice this makes MobX applications very well optimized out of the box and they typically don’t need any additional code to prevent excessive rendering.

For observer to work, it doesn’t matter how the observables arrive in the component, only that they are read. Reading observables deeply is fine, complex expression like todos[0].author.displayName work out of the box. This makes the subscription mechanism much more precise and efficient compared to other frameworks in which data dependencies have to be declared explicitly or be pre-computed (e.g. selectors).

FAQs

Property ‘timer’ does not exist on type ‘{ children?: ReactNode; }’. TS2339

Declare { timer } : { timer: Timer } type to fix that issue.

1
2
3
4
5

Property 'timer' does not exist on type '{ children?: ReactNode; }'.  TS2339

    20 | // A function component wrapped with `observer` will react
    21 | // to any future change in an observable it used before.
  > 22 | const TimerView = observer(({ timer }) => <span>Seconds passed: {timer.secondsPassed}</span>)

1
2
3
4

// A function component wrapped with `observer` will react
// to any future change in an observable it used before.
- const TimerView = observer(({ timer }) => <span>Seconds passed: {timer.secondsPassed}</span>)
+ const TimerView = observer(({ timer } : { timer: Timer }) => <span>Seconds passed: {timer.secondsPassed}</span>)

Can not find module

Export component to fix that issue.

1
2
3
4
5
6
7
8

- ReactDOM.render(<TimerView timer={myTimer} />, document.body)
+ // ReactDOM.render(<TimerView timer={myTimer} />, document.body)

+ export default function TimerPage() {
+     return (
+         <TimerView timer={myTimer}></TimerView>
+     );
}

References

[1] React integration · MobX - https://mobx.js.org/react-integration.html

[2] README · MobX - https://mobx.js.org/README.html

[3] mobxjs/mobx: Simple, scalable state management. - https://github.com/mobxjs/mobx

[4] React – A JavaScript library for building user interfaces - https://reactjs.org/

[5] State and Lifecycle – React - https://reactjs.org/docs/state-and-lifecycle.html

[6] Higher-Order Components – React - https://reactjs.org/docs/higher-order-components.html

Synchronizing a Git Repository to Another: git clone --bare and git push --mirror

In the realm of software development, effective version control is paramount. Git, a powerful distributed version control system, provides robust tools for managing code repositories. However, there are scenarios where you might need to synchronize one Git repository with another. Whether it’s for backup, migration, or collaboration across different platforms, understanding how to efficiently mirror a Git repository is essential. In this blog, we’ll delve into the process of synchronizing a Git repository to another, highlighting the best practices and commands to accomplish this task.

Why Synchronize Repositories?

There are several reasons you might want to synchronize a Git repository:

1. Backup: Ensuring that your codebase is safely backed up to another location.
2. Migration: Moving your repository to a new hosting service.
3. Collaboration: Sharing the repository across different teams or organizations.
4. Redundancy: Creating multiple copies to prevent data loss.

Understanding Git Mirroring

Mirroring a Git repository means creating an exact copy of the original repository, including all branches, tags, and commit history. This is different from a simple clone, which typically only copies a single branch and doesn’t include the entire repository history by default.

Step-by-Step Guide to Synchronize Git Repositories

Let’s walk through the process of synchronizing a Git repository to another using the git clone --bare and git push --mirror commands.

1. Cloning the Repository as Bare

A bare repository is a Git repository that doesn’t have a working directory. It only contains the Git directory, making it suitable for mirroring and sharing.

1

git clone --bare <source_repo_url>

Replace <source_repo_url> with the URL of your source repository. This command will create a bare copy of the repository.

1
2

# Example
git clone --bare https://github.com/username/source_repo.git

This command creates a new directory named source_repo.git that contains the bare repository.

2. Pushing the Bare Repository to the Target

Once you have a bare clone of the source repository, you can push it to the target repository using the --mirror flag. The --mirror flag ensures that all references (branches, tags, etc.) are copied to the target repository.

1
2

cd source_repo.git
git push --mirror <target_repo_url>

Replace <target_repo_url> with the URL of your target repository.

1
2

# Example
git push --mirror https://github.com/username/target_repo.git

This command pushes all branches, tags, and references from the source repository to the target repository.

3. Regular Synchronization

To keep the target repository synchronized with the source repository, you can set up a periodic job (e.g., a cron job) that fetches updates from the source repository and pushes them to the target repository.

1
2
3
4
5

# Fetch updates from the source repository
git fetch --all

# Push updates to the target repository
git push --mirror <target_repo_url>

Best Practices

1. Authentication: Ensure that you have the necessary authentication set up for both source and target repositories. This could involve SSH keys or personal access tokens.
2. Error Handling: Implement error handling in your synchronization scripts to handle network issues or authentication failures gracefully.
3. Monitoring: Set up monitoring and alerts to notify you if the synchronization fails.
4. Security: Keep your repositories secure by using encrypted connections (HTTPS or SSH) and managing access controls.

Conclusion

Synchronizing a Git repository to another is a valuable skill for maintaining code integrity, enabling seamless migration, and ensuring robust backups. By using the git clone --bare and git push --mirror commands, you can create an exact copy of your repository, including all branches, tags, and commit history. Remember to follow best practices for authentication, error handling, monitoring, and security to ensure a smooth and reliable synchronization process.

By mastering these techniques, you can enhance your workflow and ensure that your code repositories are always up-to-date and securely backed up, ready to support your development endeavors. Happy coding!

Additional Resources

• Git Documentation
• GitHub Guides
• GitLab Documentation
• Bitbucket Documentation

Feel free to reach out if you have any questions or need further assistance with Git repository synchronization!

asdf and Erlang Plugin

asdf is a single CLI tool for managing multiple runtime versions. It extend with a simple plugin system to install your favourite language: Dart, Elixir, Erlang, Flutter, Golang (Go), Java, Node.js, Python, Ruby …

This article is about how to use asdf and Elixir plugin to install multiple Elixir versions on macOS with the Homebrew package manager.