19,785 Matching Annotations
  1. Nov 2022
    1. Since Mash is conceived to provide psuedo-object functionality, handling keys which cannot represent a method call falls outside its scope of value.
    2. Hashie does not have built-in support for coercing boolean values, since Ruby does not have a built-in boolean type or standard method for coercing to a boolean. You can coerce to booleans using a custom proc.

      I use: ActiveRecord::Type::Boolean.new.cast(value)

    3. Note: The ? method will return false if a key has been set to false or nil. In order to check if a key has been set at all, use the mash.key?('some_key') method instead.
    4. Mash is an extended Hash that gives simple pseudo-object functionality that can be built from hashes and easily extended. It is intended to give the user easier access to the objects within the Mash through a property-like syntax, while still retaining all Hash functionality.
    5. user.deep_fetch :groups, 1, :name

      similar to: dig

    6. Though this is a hash extension, it conveniently allows for arrays to be present in the nested structure. This feature makes the extension particularly useful for working with JSON API responses.
    7. Value coercions, on the other hand, will coerce values based on the type of the value being inserted. This is useful if you are trying to build a Hash-like class that is self-propagating.
    1. In our system, events are generated by physical hosts and follow different routes to the event storage. Therefore, the order in which they appear in the storage and become retrievable - via the events API - does not always correspond to the order in which they occur. Consequently, this system behavior makes straight forward implementation of event polling miss some events. The page of most recent events returned by the events API may not contain all the events that occurred at that time because some of them could still be on their way to the storage engine. When the events arrive and are eventually indexed, they are inserted into the already retrieved pages which could result in the event being missed if the pages are accessed too early (i.e. before all events for the page are available). To ensure that all your events are retrieved and accounted for please implement polling the following way:
    1. A SimpleDelegator instance can take advantage of the fact that SimpleDelegator is a subclass of Delegator to call super to have methods called on the object being delegated to. class SuperArray < SimpleDelegator def [](*args) super + 1 end end SuperArray.new([1])[0] #=> 2
    1. Bash maintains an internal hash of previously found executables in your path. In this case, it has details that at one time there was an executable at /usr/bin/siege, and reuses that path to avoid having to search again. You need to tell bash to manually rehash the path for siege like so: hash siege You can also clear all hashed locations: hash -r
    1. Remember there are two kinds of variable. Internal Variables and Environment Variables. PATH should be an environment variable.

      In my case, I was trying to debug which asdf not finding asdf, in a minimal shell.

      I had checked bash-5.1$ echo $PATH|grep asdf /home/tyler/.asdf/bin

      but ```

      The PATH environment variable

      env | /bin/grep PATH `` being empty was the key discovery here. Must have forgotten theexport`.

    2. All shells should tell you that your path is the same thing with BOTH of the two commands: # The PATH variable echo "$PATH" # The PATH environment variable env | /bin/grep PATH
    1. In v3, svelte-preprocess was able to type-check Svelte components. However, giving the specifics of the structure of a Svelte component and how the script and markup contents are related, type-checking was sub-optimal. In v4, your TypeScript code will only be transpiled into JavaScript, with no type-checking whatsoever. We're moving the responsibility of type-checking to tools better fit to handle it, such as svelte-check, for CLI and CI usage, and the VS Code extension, for type-checking while developing.
    1. Undecided yet what bundler to use? We suggest using SvelteKit, or Vite with vite-plugin-svelte.

      Undecided?

    1. You're likely not using "type": "module" in your package.json, so import statements don't work in svelte.config.js. You have three ways to fix this: Use require() instead (also see https://github.com/sveltejs/language-tools/blob/master/docs/preprocessors/in-general.md#generic-setup) Rename svelte.config.js to svelte.config.mjs Set "type": "module" in your package.json (may break other scripts)
    1. Warning: This ignores the user's keyboard layout, so that if the user presses the key at the "Y" position in a QWERTY keyboard layout (near the middle of the row above the home row), this will always return "KeyY", even if the user has a QWERTZ keyboard (which would mean the user expects a "Z" and all the other properties would indicate a "Z") or a Dvorak keyboard layout (where the user would expect an "F"). If you want to display the correct keystrokes to the user, you can use Keyboard.getLayoutMap().

      Wow, that's quite a caveat!

    1. It would probably be worth mentioning this explicitly in the README: "Configuration of the language server happens over the LSP protocol by passing a configuration object; your LSP client should have a way of setting the configuration object for a server. Here is a link to the spec for the configuration that is supported [...]"
    1. So when configuring Capybara, I'm using ignore_default_browser_options, and only re-use this DEFAULT_OPTIONS and exclude the key I don't want Capybara::Cuprite::Driver.new( app, { ignore_default_browser_options: true, window_size: [1200, 800], browser_options: { 'no-sandbox': nil }.merge(Ferrum::Browser::Options::Chrome::DEFAULT_OPTIONS.except( "disable-features", "disable-translate", "headless" )), headless: false, } )
    1. You can definitely set the Return-Path header as a sender. But yes, some receivers might rewrite it (But not always ), or depending on who you're sending through, it might be re-written by them. For instance when using MailGun to send bulk email you have to do things just right in order to set a Return-Path that will be preserved. I know this contradicts the RFC you cite, but it's in practice true.
    2. Return-Path header is written by the receiving server, not by the sending server. And as per the RFC 5321, it is the same as the address supplied in MAIL FROM command.
    1. Do you know about lacolhost.com? as in, do something like blerg.lacolhost.com:3000/ as your url and it'll resolve to localhost:3000, which is where your tests are running.
    2. I have DNS settings in my hosts file that are what resolve the visits to localhost, but also preserve the subdomain in the request (this latter point is important because Rails path helpers care which subdomain is being requested)
    3. I've developed additional perspective on this issue - I have DNS settings in my hosts file that are what resolve the visits to localhost, but also preserve the subdomain in the request (this latter point is important because Rails path helpers care which subdomain is being requested) To sum up the scope of the problem as it stands now - I need a way within Heroku/Capybara system tests to both route requests to localhost, but also maintain the subdomain information of the request. I've been able to accomplish one or the other, but haven't found a configuration that provides both yet.
    1. Benoit Daloze of TruffleRuby points out that this is all much easier to read if you define your Ruby internals in Ruby, like they do. He's not wrong.
    2. first we're looking for the "main" object. The word "main" is used in lots of places in Ruby, so that will be hard to track down. How else can we search?Luckily, we know that if you print out that object, it says "main". Which means we should be able to find the string "main", quotes and all, in C.
    1. Refresh tokens are bearer tokens. It's impossible for the authorization server to know who is legitimate or malicious when receiving a new access token request. We could then treat all users as potentially malicious.
    2. How could we handle a situation where there is a race condition between a legitimate user and a malicious one?
    1. There are also many reasons refresh tokens may expire prior to any expected lifetime of them as well.

      such as...?

    2. You might notice that the “expires_in” property refers to the access token, not the refresh token. The expiration time of the refresh token is intentionally never communicated to the client. This is because the client has no actionable steps it can take even if it were able to know when the refresh token would expire.
    1. But what about a Refresh Token flow? When using a refresh token, confidential clients also have to authenticate. Public clients, such as browser-based applications, do not authenticate during the Refresh Token flow. So in a typical frontend application, refresh tokens issued to frontend web applications are bearer tokens.   In practice, this means that if an attacker manages to steal a refresh token from a frontend application, they can use that token in a Refresh Token flow. To counter such attacks, the OAuth 2.0 specifications mandate that browser-based applications apply a security measure known as refresh token rotation.
    1. you can use a Backend for Frontend (BFF)

      first sighting: Backend for Frontend

    2. Grant Types
    3. For example, if I make an application (Client) that allows a user (Resource Owner) to make notes and save them as a repo in their GitHub account (Resource Server), then my application will need to access their GitHub data. It's not secure for the user to directly supply their GitHub username and password to my application and grant full access to the entire account. Instead, using OAuth 2.0, they can go through an authorization flow that will grant limited access to some resources based on a scope, and I will never have access to any other data or their password.
    1. Until now, we had a lot of code. Although we were using a plugin to help with boilerplate code, ready endpoints, and webpages for sign in/sign up management, a lot of adaptations were necessary. This is when Doorkeeper comes to the rescue. It is not only an OAuth 2 provider for Rails but also a full OAuth 2 suite for Ruby and related frameworks (Sinatra, Devise, MongoDB, support for JWT, and more).
    2. The process used to create an OAuth wrapper client is very simple.
    1. This document defines how a JWT Bearer Token can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of the JWT, without a direct user-approval step at the authorization server.

      [transfer fo trust/credentials]

    1. Can I try the endpoints before I implement my application?
    2. If the Client is a Single-Page App (SPA), an application running in a browser using a scripting language like JavaScript, there are two grant options: the Authorization Code Flow with Proof Key for Code Exchange (PKCE) and the Implicit Flow with Form Post. For most cases, we recommend using the Authorization Code Flow with PKCE because the Access Token is not exposed on the client side, and this flow can return Refresh Tokens.
    3. Is the Client absolutely trusted with user credentials?
    4. Which OAuth 2.0 Flow Should I Use?
    5. If the Client is a regular web app executing on a server, then the Authorization Code Flow is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token.
    6. The first decision point is about whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed.
    1. you will need to add a few more braces

      If "brace" means {}, then this is incorrect. A few more parentheses, (), is correct.

    1. The Console now supports redeclaration of const variables across separate REPL scripts (such as when you run a statement in the Console), in addition to the existing let and class redeclarations. This support allows you to experiment with different declarations for const variables without refreshing the page. Previously, DevTools threw a syntax error if you redeclared a const binding.

      Edge version of this matching release note from the matching Chrome feature:

      https://hyp.is/d9XEKGfOEe2a27vFWUjjSA/developer.chrome.com/blog/new-in-devtools-92/

      Interesting, they're copying some content, but not all of it verbatim.

    1. The Console now supports redeclaration of const statement, in addition to the existing let and class redeclarations. The inability to redeclare was a common annoyance for web developers who use the Console to experiment with new JavaScript code.
    1. Note that strings here are encoded as UTF-8, unlike the usual JavaScript UTF-16 strings.
    1. binary string (i.e., a string in which each character in the string is treated as a byte of binary data)
    2. convert the string such that each 16-bit unit occupies only one byte

      What is a 16-bit "unit"?

      How can a 16-bit unit fit in 8 bits (1 byte)?

    3. The btoa() function takes a JavaScript string as a parameter. In JavaScript strings are represented using the UTF-16 character encoding: in this encoding, strings are represented as a sequence of 16-bit (2 byte) units. Every ASCII character fits into the first byte of one of these units, but many other characters don't. Base64, by design, expects binary data as its input. In terms of JavaScript strings, this means strings in which each character occupies only one byte. So if you pass a string into btoa() containing characters that occupy more than one byte, you will get an error, because this is not considered binary data:
    4. If you need to encode Unicode text as ASCII using btoa(), one option is to convert the string such that each 16-bit unit occupies only one byte.
    1. Honestly, at this point, I don't even know what tools I'm using, and which is responsible for what feature. Diving into the code of capybara and cucumber yields hundreds of lines of metaprogramming magic that somehow accretes into a testing framework. It's really making me loathe TDD despite my previous youthful enthusiasm.

      opinion: too much metaprogramming magic

      I'm not so sure it's "too much" though... Any framework or large software project is going to feel that way to a newcomer looking at the code, due to the number of layers of abstractions, etc. that eventually were added/needed by the maintainers to make it maintainable, decoupled, etc.

    2. Wow, the man himself.
    1. Please refer to the help center for possible explanations why a question might be removed.

      Why not just show the page and let people see the content and decide for themselves if it's helpful? (Could also show the moderation outcome there, with the reason.)

    2. This question was removed from Stack Overflow for reasons of moderation.
    1. So far for the obligatory warning. I get the point, I even agree with the argument, but I still want to send a POST request. Maybe you are testing an API without a user interface or you are writing router tests? Is it really impossible to simulate a POST request with Capybara? Nah, of course not!
    2. The Capybara Ruby gem doesn’t support POST requests, the built-in visit method always uses GET. This is by design and with good reason: Capybara is built for acceptance testing and a user would never ask to ‘post’ parameter X and Y to the application. There will always be some kind of interface, a form for example. It makes more sense to simulate what the visitor would really do
    1. module InjectSession include Warden::Test::Helpers def inject_session(hash) Warden.on_next_request do |proxy| hash.each do |key, value| proxy.raw_session[key] = value end end end end
    1. This site is making use of some basic analytics cookies so I can hopefully learn something from of the metrics. By using the site you are totally fine with that.
    2. And with diagrams as text close to the code chances are they will be kept to up to date (and created to begin with…).
    3. There IS a super nice Visual Studio Code plugin for it but it still comes with the environment pre-reqs AS well as the cumbersome pressing of Alt-D (or was it Ctrl-D??) to get the preview. For other IDE’s I bet there are similar plugins leaving the same nasty taste of dissatisfaction… and the pollution of your environment.
    1. You may want to change the controllers to your custom controllers with: Rails.application.routes.draw do use_doorkeeper do # it accepts :authorizations, :tokens, :token_info, :applications and :authorized_applications controllers :applications => 'custom_applications' end end
    2. If you want to extend the default behaviour, just inherit from Doorkeeper::ApplicationsController. For example: class CustomApplicationsController < Doorkeeper::ApplicationsController end
    1. This is ugly by design, as an inducement to test properties instead of specifics.
    2. So transcriptor aims to do less, and impose the bare minimum of cognitive load needed to convert a REPL interaction into a test. The entire API is four functions:
    3. Testing frameworks often introduce their own abstractions for e.g. evaluation order, data validation, reporting, scope, code reuse, state, and lifecycle. In my experience, these abstractions are always needlessly different from (and inferior to) related abstractions provided by the language itself.
    1. Check the "Auto-open DevTools for popups".

      Without this feature, when a pop-up opens without DevTools open, if it redirects, it will be too late to open DevTools and see the redirect logged...

      There is still a problem though: If the pop-up window closes, so does that DevTools. So you can't see logs or network logs (redierects) that happened right before it closed...

    1. I just assumed that nesting/inheriting settings would be a thing because of course it would
    2. git_workspace/ ├── .vscode │ └── settings.json # global settings, my preferred ones ├── my-personal-projects/ │ └── project1/ │ └── .git/ └── company-projects/ ├── .vscode │ └── settings.json # local settings, overrides some of my personal ones ├── project2/ │ └── .git/ └── project3/ └── .git/
    1. As you note, Activity diagrams inherently can include concurrency and timing. If you look at this example cribbed from Wikipedia, shown below, you can observe the section with two heavy horizontal bars, and two parallel activities of "present idea" and "record idea". That is read as "start these activities in parallel, and continue only when both are complete." Flowcharts can't express this within the notation. Practically, using activity diagrams lets you think clearly about concurrent processes. I think you'll find that anyone who can read a flowchart will quickly adapt.
    2. Activity diagram spreads confusion by its own name, there must be a reason why nobody understand them and ask similar questions.
    3. It might seem as a preference, but if we have a standardized language for describing software systems, Why do we use something else? This can lead to bad habit of overusing flowcharts. Activity diagrams are really simple. But if you decide to describe a more complicated aspect of the system or try to change the part you are describing, you might have to switch anyway. So just use UML and prevent confusion in the future.
    4. assuming a standard is better because the standard says so, it is like that old while(1) infinite loop it is better not to enter.
    1. to set up
    2. It is handy to manually generate the diagram from times to times using the previously created command: npm run db:diagram:generate. Though, getting the diagram to update itself on its own automatically without a developer interaction would ensure that it the diagram is never obsolete. There are several ways of doing this.You could use a pre-commit git hook or even better simply configure your CI/CD pipeline(s) to run the npm script whenever something gets merged into the main branch 🙂
    3. When it comes to showing up somewhere in your documentation a diagram describing your SQL database, you often end up with a recurring problem : after a few days / weeks / months, the diagram you made became obsolete.
    1. It would be nice if we could get some official word on whether this repository is affect by the catastrophic CVE-2021-44228 that is currently affecting a considerable percentage of softwares around the globe. From my limited understanding and looking at the refreshingly concise list of dependencies in the pom.xml, I would think this project is not affected, but I and probably others who are not familiar with the projects internals would appreciate an official word.
    2. I understand that typically, it wouldn't make much sense to comment on every CVE that doesn't affect a product, but considering the severity and pervasiveness of this particular issue, maybe an exception is warranted.
    1. I agree that these fields should be whitelisted by ActiveAdmin automatically as it generates them via the form helpers. Regardless of if you use :raise or :log you wouldn't usually want these causing unnecessary noise.
    1. I don't think a new tag makes sense here, at least not yet.
    2. Once "Containerfile" starts becoming less of a whisper and more of the topic, then perhaps we can talk about a synonym. But definitely not now.
    3. creating the new tag as a synonym.
    4. Yes, it was right, but nowadays Dockerfiles are not specific to Docker. Dockerfiles also work with Buildah & Podman (and there might be other ones in the future) and they have generalized the naming: “Containerfile.”
    5. Docker suffers from the Xerox problem. Like it or not the industry refers to them as Dockerfiles.

      But the industry can change what they call it... just like it's already changed - from "master" to "main" - from "blacklist" to "blocklist" - and so on

    6. They are 100% identical; just different names. From podman-build: “Builds an image using instructions from one or more Containerfiles or Dockerfiles and a specified build context directory. A Containerfile uses the same syntax as a Dockerfile internally. For this document, a file referred to as a Containerfile can be a file named either ‘Containerfile’ or ‘Dockerfile’.”
    1. Post.in_order_of(:type, %w[Draft Published Archived]).order(:created_at).pluck(:name) which generates SELECT posts.name FROM posts ORDER BY CASE posts.type WHEN 'Draft' THEN 1 WHEN 'Published' THEN 2 WHEN 'Archived' THEN 3 ELSE 4 END ASC, posts.created_at ASC
    1. Changing the second line to: foo.txt text !diff would restore the default unset-ness for diff, while: foo.txt text diff will force diff to be set (both will presumably result in a diff, since Git has presumably not previously been detecting foo.txt as binary).

      comments for tag: undefined vs. null: Technically this is undefined (unset, !diff) vs. true (diff), but it's similar enough that don't need a separate tag just for that.

      annotation meta: may need new tag: undefined/unset vs. null/set

    1. Unspecified No pattern matches the path, and nothing says if the path has or does not have the attribute, the attribute for the path is said to be Unspecified.
    2. Unset The path has the attribute with special value "false"; this is specified by listing the name of the attribute prefixed with a dash - in the attribute list.
    1. The second situation would be zombie reaping. If the process spawns child processes and does not properly reap them it will lead to a full process table
    2. For both of these concerns we recommend tini. It is incredibly small, has minimal external dependencies, fills each of these roles, and does only the necessary parts of reaping and signal forwarding.
    3. The first being signal handling. If the process launched does not handle SIGTERM by exiting, it will not be killed since it is PID 1 in the container
    4. There are two situations where an init-like process would be helpful for the container.
    5. highly recommended that the resulting image be just one concern per container; predominantly this means just one process per container, so there is no need for a full init system

      container images: whether to use full init process: implied here: don't need to if only using for single process (which doesn't fork, etc.)

    6. Try to make the Dockerfile easy to understand/read.
    7. # check for the expected command if [ "$1" = 'mongod' ]; then # init db stuff.... # use gosu (or su-exec) to drop to a non-root user exec gosu mongod "$@" fi # else default to run whatever the user wanted like "bash" or "sh" exec "$@"
    8. A beginning user should be able to docker run official-image bash (or sh) without needing to learn about --entrypoint.
    9. It is also nice for advanced users to take advantage of entrypoint, so that they can docker run official-image --arg1 --arg2 without having to specify the binary to execute.
    10. For dependent packages installed by apt there is not usually a need to pin them to a version.

      Just install the specific initial version, but don't pin it. This allows users to easily update to later versions later...

    11. For example, if using apt to install the main program for the image, be sure to pin it to a specific version (ex: ... apt-get install -y my-package=0.1.0 ...)
    12. Rebuilding the same Dockerfile should result in the same version of the image being packaged, even if the second build happens several versions later, or the build should fail outright, such that an inadvertent rebuild of a Dockerfile tagged as 0.1.0 doesn't end up containing 0.2.3.
    13. Version bumps and security fixes should be attended to in a timely manner.
    14. If you do not represent upstream and upstream becomes interested in maintaining the image, steps should be taken to ensure a smooth transition of image maintainership over to upstream.
    15. Because the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed Dockerfile to ensure that it meets a minimum standard for quality and maintainability. While some of that standard is hard to define (due to subjectivity), as much as possible is defined here, while also adhering to the "Best Practices" where appropriate.
    16. It may be tempting, for the sake of brevity, to put complicated initialization details into a standalone script and merely add a RUN command in the Dockerfile. However, this causes the resulting Dockerfile to be overly opaque