Quoting:
"Property-based testing (PBT) relies on properties which can be written in pseudocode as:
for all (x, y, ...)
such as precondition(x, y, ...) holds
property(x, y, ...) is true
Well, as the title states we'll be addressing software development topics (mainly in English). Topics will be quick and short and most probably aligned with the training "problems", sorry, programs I am involved in. PS. Some links are "internal" (not publicly available): If you are not able to reach it, google will find you a publicly available information source for sure. Happy trails to you.
for all (x, y, ...)
such as precondition(x, y, ...) holds
property(x, y, ...) is true
Oh, did I ever tell you you need to take (efficiently) print screens while (manual) testing? Some ideas towards productivity:
https://www.pcmag.com/feature/370572/how-to-take-screenshots-in-windows-10
PS: Also do not forget the utility "mouse without borders" also crucial for testers (with 2 or more PCs and just one mouse).
Yes. It's called suggestions. Share with Edit permissions. Uncheck the email notifications. Much like MS Office, comments also exist in Google Docs as well as a Compare option in tools and a revision history (with human readable names that can be set by the user):
https://www.pcmag.com/article/330137/tip-how-to-use-track-changes-in-google-docs
Missing TBC: The Combine (with generated inline tracked changes) option, much useful to know what words changed between 2 revisions when someone forgot (or "forgot") to start tracking changes. If you have PDF versions attempt a conversion of PDF to docx and then combine (Office does it).
Documentation IS part of the configuration of a software so, do learn to use productivity tools. This is why it's called productivity tools.
For example, if product development wants to skimp on testing or increase push velocity and SRE is resistant, the error budget guides the decision. When the budget is large, the product developers can take more risks. When the budget is nearly drained, the product developers themselves will push for more testing or slower push velocity, as they don’t want to risk using up the budget and stall their launch. In effect, the product development team becomes self-policing. They know the budget and can manage their own risk. (Of course, this outcome relies on an SRE team having the authority to actually stop launches if the SLO is broken.)"
Quoting Java Performance Newsletter:
""The 10 Common Concurrency Models" from this month's Devoxx
https://www.youtube.com/watch?v=PNx9WqQ9QeA
is just a 15 minute whirlwind tour that explains why there are so many
of these models for you to choose from, yet without a clear winner."
https://www.infoq.com/news/2019/04/java-logging-framework-flogger
Quoting:
"new open-source Java logging framework called Flogger. Acknowledging that "[t]he field of open-source Java logging APIs is already extremely crowded", Google asserts that Flogger offers "many benefits over existing logging APIs". These improvements include reducing the cost of disabled log statements, increasing overall readability, and allowing extensibility.
Flogger, a portmanteau of fluent and logger, argues that one of its main benefits is "[l]ogging at disabled levels is effectively free." Whereas other logging frameworks may generate bytecode for disabled logging statements, Flogger aims to completely avoid it.
More specifically, logging frameworks typically utilize varargs to accommodate the unknown number of parameters in a logging method call rather than having hundreds or even thousands of different and unpredictable method signatures. This use of varargs results in additional bytecode, particularly to allocate an Object[] for storing the varargs. While additional bytecode doesn’t typically warrant concern, it becomes particularly important in applications with very fine-grained logging statements or logging statements that occur in loops."
This:
https://www.w3.org/TR/webauthn/
Quoting:
"The below use case scenarios illustrate use of two very different types of authenticators, as well as outline further scenarios. Additional scenarios, including sample code, are given later in §12 Sample Scenarios.
1.2.1. Registration
On a phone:
User navigates to example.com in a browser and signs in to an existing account using whatever method they have been using (possibly a legacy method such as a password), or creates a new account.
The phone prompts, "Do you want to register this device with example.com?"
User agrees.
The phone prompts the user for a previously configured authorization gesture (PIN, biometric, etc.); the user provides this.
Website shows message, "Registration complete."
1.2.2. Authentication
On a laptop or desktop:
User pairs their phone with the laptop or desktop via Bluetooth.
User navigates to example.com in a browser and initiates signing in.
User gets a message from the browser, "Please complete this action on your phone."
Next, on their phone:
User sees a discrete prompt or notification, "Sign in to example.com."
User selects this prompt / notification.
User is shown a list of their example.com identities, e.g., "Sign in as Alice / Sign in as Bob."
User picks an identity, is prompted for an authorization gesture (PIN, biometric, etc.) and provides this.
Now, back on the laptop:
Web page shows that the selected user is signed in, and navigates to the signed-in page. (...)"
... passwords. A list of the 100000 most common of them BTW:
https://www.ncsc.gov.uk/blog-post/passwords-passwords-everywhere
Quoting:
"I'm a developer. What should I do with these files?
If your product is unlikely to have access to the internet when deployed (or you don't want to rely on an external service), you can include a check against one of these files in your authentication flow. It's up to you how you handle cases where the password matches one of these, but you should enable users to use tools such as password managers.
If you can make use of an external service, there are options such as Troy Hunt's Pwned Passwords API. Troy has written a really good blogcovering how different companies have implemented this feature, that may help you to design your own flow.
Alternatively, look at ways to reduce the load on your users by looking at alternative authentication flows (like supporting single sign-on), and by keeping an eye on upcoming standards such as WebAuthn - we'll have more on this in the future."
Principles, books, tools for productivity and metrics and more:
https://www.dotnetcurry.com/patterns-practices/1358/code-quality-tools
An interview with the authors can be found here:
https://www.infoq.com/articles/book-review-optimizing-java
Quoting:
"Key Takeaways
Performance tuning in Java is an experimental science.
There are no magic “go faster” command-line switches for the JVM.
There are no “tips and tricks” to make Java run faster.
The execution speed of Java code is highly dynamic and fundamentally depends on the underlying JVM.
The behavior of JIT-compiled code is significantly more important than the interpreter itself.
This book offers both theory and practice on how to performance tune in Java.
This is a comprehensive book that represents a tutorial for beginners and a reference for experienced Java performance tuning practitioners."
See also: JITwatch