iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🏴‍☠️

Productivity Weekly (2022-07-13)

に公開
ProductivityWeekly
生産性向上
idea

Hello. This is Hirakiba from the Productivity Improvement Team at Cybozu Inc.

Every Wednesday, our Productivity Improvement Team holds an internal meeting called "Productivity Weekly," where we share topics discovered during the week related to improving developer productivity.
This article is a compilation of those topics.

This is the 82nd edition. You can find past articles here.

news 📺

The VS Code Server

https://code.visualstudio.com/blogs/2022/07/07/vscode-server

The VS Code Server, a backend service for VS Code (supporting extensions, terminal, debugging, etc.), and its management CLI, code-server, have been released (private preview).

By setting it up, you can develop in your environment via the web, allowing you to jump straight into development without having to set up your local machine's environment. I think it's similar to an on-premises version of GitHub Codespaces. As it is currently in private preview, you need to sign up for the waitlist to use it.

There are two connection modes: connecting locally and connecting via a tunnel through vscode.dev. In the case of tunnel connections, since it involves opening a hole in the network (though authentication mechanisms exist), you should be cautious about using it at work. You might think, "Why not just use Remote SSH?" but according to the official documentation, it addresses needs such as when SSH is restricted or when you want to develop in environments where the native VS Code app is unavailable (like on an iPad or Chromebook).

Since it is intended for one user per instance, it seems difficult to prepare one high-spec instance for everyone to develop on together. However, depending on how it's used, it might be possible to deploy multiple instances so that any developer can jump into development immediately (though it would be tough without an authentication mechanism. In the tunnel connection mode, currently, you need to link a GitHub account when starting the server, so it seems difficult for just anyone to use).

Articles from people who have already tried it are being published:

I registered for the waitlist on the announcement day and received an invitation about three days later.
My impressions after trying it out for a bit are:

  • Extensions and other features work without any particular issues.
  • The two articles mentioned above stated that tunnel connections were not yet supported, but it was already available when I tried it.
  • When I started it with a local connection and tried to connect via https through a reverse proxy, a CORS error occurred and I couldn't launch it in the browser (related Issue).
  • Regarding multi-user development:
    • With tunnel connections, since authentication is done via GitHub accounts, it seems possible to identify who executed a command when multiple people access the same server.
    • With local connections, there doesn't seem to be an authentication mechanism yet, so it might be difficult to identify who executed a command.
    • (Reiteration) It is primarily designed for one user per instance.

      • Is the VS Code Server designed for multiple users to access the same remote instance?
        No, an instance of the server is designed to be accessed by a single user.

  • You can access it from a browser now, but access from the native VS Code app doesn't seem possible yet?

Since it's still in the preview stage, there are unstable parts and specifications might change, so it's only suitable for experimentation for now, but it looks like interesting things will be possible once it's officially released.

It seems possible even now to set it up on a home Raspberry Pi and develop from an iPad via a tunnel connection, so it might already be usable for personal development. Looking forward to it.

Extend AWS IAM Roles to Workloads Outside of AWS with IAM Roles Anywhere | Amazon Web Services Blog

https://aws.amazon.com/blogs/aws/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/

AWS has released IAM Roles Anywhere, a feature that provides temporary IAM credentials to workloads outside of AWS. By registering a Certificate Authority (CA) from a Public Key Infrastructure (PKI) as a trusted anchor in IAM Roles Anywhere, you can obtain temporary credentials by passing an X.509 certificate issued by that trusted CA to IAM Roles Anywhere.

Because this eliminates the need to store long-term AWS credentials, it is considered more secure. It removes the hassle of manual credential rotation, and even if a credential is leaked, the session remains valid for only a short period.

Several people have already tried this out (the folks at Classmethod were quick as usual).

To be honest, while I know about PKI in theory, I had never worked with it practically, so I tried out various methods from the articles above. The method using Vault was the easiest to test. It was truly simple.

Here are some of my thoughts on this feature:

  • While you don't have to store AWS credentials, using aws_signing_helper requires a plaintext private key, so the private key must be placed on the server that issues the AWS credentials. In the end, if the private key is leaked, credentials can be issued freely.
  • aws_signing_helper is not open source, so we don't know what's happening internally, and you have to pass it the path to a plaintext private key.
  • I'm not sure how to restrict which profiles can be used per trust anchor.
    • Maybe it can be done by fine-tuning the trust policies of the roles linked to the profiles? I'd like to see some examples of how to do this.
  • If the machine issuing the AWS credentials is different from the machine calling the AWS APIs, a vulnerability in the API-calling program shouldn't lead to a private key leak.
    • The problem is how to pass the AWS credentials between them. That seems like a hassle to figure out.
    • For example, if the machine issuing the AWS credentials calls the API within a Docker container, passing the credentials might be easier.

      • I actually tried this. It can be done like this:

        aws_config (Setting to read the credential JSON obtained by aws_signing_helper)
        [default]
credential_process = cat /aws_credentials.json
        aws-cli.sh
        #!/usr/bin/env bash

# Obtain temporary IAM credentials
./aws_signing_helper credential-process \
--certificate $CERTIFICATE_FILE_PATH \
--private-key $PRIVATE_KEY_FILE_PATH \
--trust-anchor-arn $TRUST_ANCHOR_ARN \
--profile-arn $PROFILE_ARN \
--role-arn $ROLE_ARN > aws_credentials.json

# Use the obtained credentials within a Docker container
docker run --rm -it \
  -v $PWD/aws_credentials.json:/aws_credentials.json \
  -v $PWD/aws_config:/root/.aws/config \
  amazon/aws-cli $@

To be honest, I still don't quite understand the best way to use this (partly due to my own lack of knowledge). I hope to see more examples and case studies emerge. Also, since the only easy way to use it currently is via aws_signing_helper, I'd love to see support added to the SDKs as well.

New – Amazon EC2 M1 Mac Instances | AWS News Blog

https://aws.amazon.com/jp/blogs/aws/new-amazon-ec2-m1-mac-instances/?sc_channel=sm&sc_campaign=launch_&sc_publisher=TWITTER&sc_geo=GLOBAL&sc_outcome=awareness&sc_content=AWS_Launches&trk=launch_

Late last year, M1 Mac instances became available on Amazon EC2, and now they have finally been officially released. Previously, they were in preview and required sign-up, but now they are available to everyone.

Fine-tuning has been performed based on feedback received during the six-month preview period. Agents for Systems Manager and CloudWatch have been added, and tools like AWS CLI and AWS SDK come pre-installed.

If you're interested, give them a try (note that the minimum allocation period is 24 hours). Those who tried them during the preview period might want to re-verify the differences with the official version.

Release gopls@v0.9.0 · golang/tools

https://github.com/golang/tools/releases/tag/gopls%2Fv0.9.0

Inlay hints have been implemented in gopls, the Go language server.

Inlay hints are a specification added in Language Server Protocol 3.17. They display type information for declared variables or resolved values directly in the editor.

To try them out currently, you need to install the vscode-go extension and enable inlay hint-related features in the settings. There are currently seven types of settings available, allowing for flexible configuration.


With all settings enabled, it shows argument names and variable types.


When opening a Go file in a JetBrains IDE, argument names are shown when function arguments are literals. It has fewer features compared to VS Code using gopls. (Other languages might support variable types; settings vary by language and need to be enabled.)

The amount and type of information displayed will depend on individual preference, but finding the right settings for you should help smooth out your development process.

know-how 🎓

git 2.37 added push.autoSetupRemote to automatically set up remote tracking branches

https://twitter.com/JI/status/1546948817462800384

In git 2.37, a new setting push.autoSetupRemote was added to automatically perform --set-upstream during git push.

Have you ever tried to git push when the branch doesn't exist on the remote and gotten scolded to run git push --set-upstream origin <branch_name>? However, by setting push.autoSetupRemote to true, git push alone will automatically handle --set-upstream, so you no longer need to type git push --set-upstream origin HEAD.

If you find this tedious, give it a try. I used to manage this with an alias, but now I've added the following to my ~/.gitconfig.

.gitconfig
+ [push]
+ 	autoSetupRemote = true

Improving slow prompt display with starship + asdf - Butei's Log

https://tech.buty4649.net/entry/2021/07/29/201613

When using starship and asdf together, there is an issue where the prompt display becomes slow. This article introduces a way to improve that problem.

When I actually tried it, the prompt display did indeed get faster. However, as mentioned in the article, it is a bit tedious to have to set up .envrc and run direnv allow for every directory you want to speed up (i.e., directories containing .tool-versions).

Ultimately, I hope for improvements on the asdf side, but if the slowness is bothering you, it might be worth giving this a try.

Core concepts I value in current productivity improvement activities - Speaker Deck

https://speakerdeck.com/shibayu36/jin-falsesheng-chan-xing-gai-shan-huo-dong-deda-qie-nisiteirukao-efang

These slides introduce the core concepts valued in productivity improvement activities by someone who has been conducting such activities for nearly 10 years.

Three key concepts are shared, and all of them are very relatable. In particular, the point about "Always looking at team productivity improvement through numbers, but not judging by numbers alone" was quite insightful. (In the Productivity Improvement Team I belong to, we don't measure productivity quantitatively based on the idea that observing only numbers can lead to misidentifying problems, as mentioned in the slides. However, recently I personally feel the need for some kind of indicator, so these related thoughts are very helpful.)

I believe those involved in productivity improvement will find the concepts presented here quite useful.

Making Pull Requests traceable from the GitHub Actions job execution screen - Lambda Cocktail

https://blog.3qe.us/entry/2022/07/12/195023

This article introduces a method to trace the source pull request from the GitHub Actions job execution screen.

Even when a GitHub Actions job is triggered by a pull request, the execution screen does not provide a link back to that pull request, which is inconvenient. This article explains in detail how to write a link to the pull request into the Job Summary at the end of the job.

Since having a link to the pull request is undoubtedly convenient, I recommend this to anyone who finds the current setup frustrating. However, since it is a lot of work to set this up for every job, I honestly wish it were an official feature.

tool 🔨

Release Add support for asdf format and update actions/cache version to 3.0.0 · actions/setup-node

https://github.com/actions/setup-node/releases/tag/v3.4.0

In actions/setup-node, version specification supporting asdf's .tool-versions format is now available. You can set it by simply specifying the path to .tool-versions in node-version-file.

This is a great feature for people using asdf. While this update is for actions/setup-node, I hope this feature comes to other actions/setup-* as well.

koneta 🍘

This is a corner for topics that came up in Productivity Weekly but weren't fully covered because I didn't have enough energy or because there wasn't much to say about them.

Afterword

It's late, but here is the 2022/07/13 issue. I spent time on my presentation at DevSumi and exploring AWS IAM Roles Anywhere, which caused the delay. Specifically, I spent almost my entire weekend on just IAM Roles Anywhere.

The materials I presented at DevSumi are in the "omake" section below, so please check them out if you're interested.

The Productivity Improvement Team at Cybozu works on activities to improve the development productivity of our internal engineers. If you're interested in our team, click the link below!
https://note.com/cybozu_dev/n/n1c1b44bf72f6

omake 🃏: Developer productivity support is not straightforward — How to deal with challenges that arise while promoting improvements | Docswell

https://www.docswell.com/s/korosuke613/59Y1MK-2022-07-21-fighting-the-problems-that-come-with-developer-productivity-support

This week's bonus. It's more of a promotion than a bonus. These are the materials I presented at Developers Summit 2022 Summer. I talked about the reason for the Productivity Improvement Team's existence and how to deal with the challenges that arise during improvement activities.

The content was timed to end exactly in 40 minutes, so I couldn't look at the chat much, but I was happy to see it was more active than I expected when I checked after finishing. There were also many questions, and I'm planning to summarize the answers in an article later, so stay tuned.

GitHubで編集を提案

Discussion