1Password Shell Plugin Update Adds Support for TreasureData Toolbelt
1Password will release an update to its shell plugin that adds support for the TreasureData Toolbelt. The TreasureData Toolbelt is a command-line interface (CLI) tool that allows users to interact with the TreasureData platform.
I have submitted a pull request to support this and it’s merged into master branch.
To use the 1Password plugin with the TreasureData Toolbelt, you must first set up the toolbelt in your environment. This involves creating a TreasureData account, obtaining an API key, and installing the toolbelt. Once the toolbelt is set up, you can build and test the TreasureData plugin locally using the instructions provided in the documentation.
$ make treasuredata/validate
$ make treasuredata/build
To import your TreasureData credentials into 1Password, you must first initialize the plugin and test the importer using the config file located at ~/.td/td.conf. The plugin will create an entry in 1Password that includes the user and api key fields. Once the credentials are saved in 1Password, you can use them to authenticate with TreasureData when running commands.
To ensure that the credentials are being properly stored and accessed at runtime, the provisioner included in the plugin will inject the TD_API_KEY environment variable when running TreasureData commands. This ensures that the toolbelt can refer to the necessary credential at runtime. To test the provisioner, run a td command and ensure that the credentials are being properly retrieved. This injection is opted out when we use the option such as -c or -k which precedes every other configuration.
Overall, the 1Password shell plugin update adds a new level of convenience and security to interacting with the TreasureData platform. With the plugin, users can easily store and access their credentials in 1Password, eliminating the need to store them in plain text or remember them.
When you try to clone the repository with HTTPS protocol, you must see the following message at least once.
$ git clone https://github.com/foo/bar.git
Cloning into 'bar'...
Username for 'https://github.com': xxx
It’s easy to resolve this issue. We just put the username and the token issued in the personal access token page in the GitHub settings.
But what if you do not have any option to set the token by yourself? In a situation like using Homebrew to clone the repository with HTTPS protocol?
We can cache the credentials of GitHub in Git so that we can use these credentials even if we do not have any way to control the external script execution.
Run gh auth login and select HTTPS as your preferred procotol.
Now, you should be able to clone the repository with HTTPS protocol without specifying the username and personal access token explicitly. Git automatically takes care of that.
Poetry allows us to manage the Python packages in a sandboxed environment neatly. My experience using Poetry was excellent, and I have replaced my Python way with Poetry from Pipenv.
But I sometimes found Poetry failed to resolve the dependencies because of the unsupported Python version used by the environment. For example, it shows the following error message.
The currently activated Python version 3.7.14 is not supported by the project (^3.9).
Trying to find and use a compatible version.
Some packages I used were not compatible with Python 3.7 in this case. But I was confused because my local PATH leads to Python 3.9 thanks to Pyenv. So how can I specify the project-specific python version?
The answer was simple. It needs to be more to specify the PATH by pyenv. We also need to set the python version by init or env use subcommands.
$ poetry init --python 3.9
OR
$ poetry env use 3.9
It tells the Poetry environment to use this Python version explicitly. With these settings, we can install all dependencies without any problem.
I used the GPG key to sign my Git commit. This is because it’s beneficial to show my commit’s identity and authenticity publicly. The signed commit, appropriately associated with the email registered in GitHub, will get the verified mark in the UI.
But you can use the SSH key to sign the commit alternatively. It’s a better and easier way because most GitHub users already should register their SSH keys to push the code to GitHub. Therefore, we do not need to prepare another key only for signing the Git commit.
First, you tell Git to use the SSH key to sign commits and tags as a default way.
At last, please make sure to register this key as a Signing keys found in the settings. I thought registering the key in Authentication keys would be enough, but it did not work. Check the Signing keys section in your GitHub account’s SSH and GPG keys setting.
That’s it. You will see your commit is appropriately verified when you submit some patches into GitHub next time.
The Date type in Rails does not retain the timezone information. The default timezone is consistent with the system Rails provides. But it’s implicit, so we should never forget which timezone we use as a Date type.
We can use in_time_zone to be explicit about which timezone we are aware of.
in_time_zone returns the TimeWithZone which inherently retains the timezone information. It’s useful to pass the timezone identifier in string type without changing the system configuration.
