You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NB: This document describles a 'Old-School' way of using Yubikey with SSH
Modern OpenSSH has native support for FIDO Authentication. Its much simpler and should also be more stable with less moving parts. OpenSSH also now has support for signing arbitary files witch can be used as replacement of gnupg. Git also supports signing commits/tags with ssh keys.
Pros of FIDO
Simpler stack / less moving parts
Works directly with ssh, ssh-add and ssh-keygen on most computers
本文譯自 Julio Merino 2018 年七月撰寫的 Rust vs. Go 一文。Julio Merino 是 G 社僱員,在 G 社工作超過 8 年,無論工作內外,都接觸開發不少 Go 語言,並撰寫 [Rust 點評][rust-review]系列文,來聽聽他對 Rust 與 Go 的想法吧。
Automatic Updating Amazon ECR Credentials in Kubernetes
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.
Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.