90 Matching Annotations
  1. Mar 2024
    1. Ironically, data brokers need to collect additional info to verify your identity and ensure they’re deleting the right person’s data.
    1. What if I don’t live in California?Only California residents have the right to data deletion under CCPA. (Why companies have the right to your data and you do not is another story. And here’s another. And another.)But some companies have said they’ll honor deletion requests no matter where you live. Spotify, Uber and Twitter said they treat deletion requests from any geographic location the same. Netflix, Microsoft, Starbucks and UPS have also said they’ll extend CCPA rights to all Americans.
    2. The company will probably ask for you to send over additional information or set up an appointment to verify your identity — that’s so no one can pretend to be you and steal or delete your data. To verify, you may need to confirm your account username and password, provide a piece of data like your phone number for the company to cross-check, or, rarely, show your government-issued ID. You should never be required to set up an account to get your data deleted, according to CCPA.
    3. People have to verify their identities before companies can delete data, which poses an extra obstacle.
    1. Nobody can see deleted accounts - not even developers. Deleted accounts are fully deleted. There's nothing to see basically by definition.
    2. There is no active user with that ID, so you cannot search by it. The whole point of deleting an account is to make it inaccessible, unreferenced, and unlinked. We're not going to implement "soft" account deletion.
    3. You cannot. And you're not supposed to. When an account is deleted, it is disassociated from all existing posts by design.
  2. Jan 2024
    1. we should break down and MR into "Blocks"
    2. Code block Metadata block Note block MR block (we should still be able to interact with the MR as a whole thing, e.g. leaving a generic comment on the whole thing)
    3. A user wants to comment on a single parameter name in a function. It is highlighted as a unique part of the syntax tree, and they're not happy with the particular name the author of the MR chose. Problem: The user can only comment on the entire line, because "lines" are considered the most fundamental building block in our Diffs UI.
    4. A user notices that an unchanged part of the diff already has features that are being implemented in the changes in the MR. The user leaves a comment on the unchanged part of the diff, telling the author that what they're trying to do is already present. Problem: The author cannot see that comment in the Changes tab, because the comment is outside the understood scope of the diff.
    5. A reviewer would like to open a discussion on the MR description because they disagree with some of the conclusions, but want more clarification. Problem: The only way to have a conversation about the MR metadata (like title, description, labels, etc.) is to open a generic note on the whole MR. There's no way to scope a discussion to a part of the MR.
  3. Mar 2023
  4. Jan 2023
    1. https://www.reddit.com/r/antinet/comments/103kpxs/table_of_contents_for_heydes_technik_des/

      Table of Contents for Heyde's Technik des wissenschaftlichen Arbeitens (1931)

      I've seen a copy of a version of the table of contents for Heyde's book in German, though I suspect it was from a version from the 1960s or after, though the copy I saw wasn't specified. Does anyone have a copy of the first edition that they could send me a photocopy of the table of contents for a project I'm working on? If you've got copies of later editions those might be useful/helpful as well.

      Heyde, Johannes Erich. Technik des wissenschaftlichen Arbeitens: zeitgemässe Mittel und Verfahrungsweisen. Junker und Dünnhaupt, 1931.

      Thanks in advance for your help!

  5. Oct 2022
  6. Jun 2022
  7. Mar 2022
    1. I used to maintain a small patch set of issues that affected me and were fixed on the GNOME bugzilla but ignored by main devs. This is was a motivating factor in my switch to to Unity years ago. Sad to hear this situation hasn't improved.
    2. I don't want to agree with you, but I tried to make a few polishing contributions to GNOME games and they got ignored after the first developer response (they told me what to fix, I fixed it). They've been stagnant for over 3 years now.
    3. Submitting changes and having them accepted by GNOME is an exercise in futility if you aren't a GNOME dev.
  8. Feb 2022
  9. Nov 2021
    1. In order to prevent this PR from becoming too large to review, I left the spread test, the part of this feature which makes it work with user daemons (left a TODO) and the addition of ~/Snap, for follow-up PRs.
  10. Jul 2021
    1. Sending body/payload in a GET request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in GET requests.
    2. Requests using GET should only be used to request data (they shouldn't include data).
    1. So long as the filters are only using GET requests to pull down links, there’s nothing fundamentally wrong with them. It’s a basic (though oft-ignored) tenet of web development that GET requests should be idempotent; that is, they shouldn’t somehow change anything important on the server. That’s what POST is for. A lot of people ignore this for convenience’s sake, but this is just one way that you can get bitten. Anyone remember the Google Web Accelerator that came out a while ago, then promptly disappeared? It’d pre-fetch links on a page to speed up things if you clicked them later on. And if one of those links happened to delete something from a blog, or log you out… well, then you begin to see why GET shouldn’t change things. So yes, the perfect solution to this is a 2-step unsubscribe link: the first step takes to you a page with a form on it, and that form then POSTs something back that finalizes the unsubscribe request.
    2. Idempotent just means that following a link twice has exactly the same effect on persistent state as clicking it once. It does not mean that following the link must not change state, just that after following it once, following it again must not change state further. There are good reasons to avoid GET requests for changing state, but that’s not what idempotent means.
  11. Mar 2021
  12. Feb 2021
    1. Source maps eliminate the need to serve these separate files. Instead, a special source map file can be read by the browser to help it understand how to unpack your assets. It "maps" the current, modified asset to its "source" so you can view the source when debugging. This way you can serve assets in development in the exact same way as in production.
    1. When Sprockets was introduced, one of the opinions that it held strongly, is that assets such as CSS and JS should be bundled together and served in one file.
    2. The alternative was to have multiple scripts or stylesheet links on one page, which would trigger multiple HTTP requests. Multiple requests mean multiple connection handshakes for each link “hey, I want some data”, “okay, I have the data”, “alright I heard that you have the data, give it to me” (SYN, ACK, SYNACK). Even once the connection is created there is a feature of TCP called TCP slow start that will throttle the speed of the data being sent at the beginning of a request to a slower speed than the end of the request. All of this means transferring one large request is faster than transferring the same data split up into several smaller requests.
    1. Here is a quick recap table of every technology we discussed in this blog post.

      Quick comparison of Python web scraping tools (socket, urlib3, requests, scrapy, selenium) [below this highlight]

    1. i2c, Inc.                  ATTN: Rob Seiler                  100 Redwood Shores Parkway                  Suite 100                  Redwood City, CA 94065
    2. courtorders@i2cinc.com
  13. Jan 2021
    1. On the linked thread I've put details, a suggestion for implementation and an offer of help if someone wants to submit a PR. Let's see what happens!

      If you've done all that work, why not just submit the PR yourself? Maybe the implementation was too incomplete/untested...

  14. Dec 2020
    1. It works very well, especially since the current Gimp roadmap relegates CMYK support to a version Gimp 3.2 However to be fairquoteShould a new developer join the team to specifically work on CMYK-related features, we will do our best to help him/her to complete this project and get it to our users as soon as possible.unquoteNot holding my breath.
  15. Nov 2020
    1. So before using GET with Body parameter, you must first ensure the servers are supporting it. It is possible that some servers might ignore the body of GET request or behavior like caching GET/HEAD requests might cause issues.
    2. A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
    1. I tried implement the retries with as little as possible change, but it's quite hard to do that and keep the code clean with the current system. If you prefer less changes, I'm happy to go back to just the first two commits:
  16. Oct 2020
  17. Sep 2020
  18. Aug 2020
    1. We've stated what's required multiple times now: #14540 (comment) #14540 (comment), and the follow up arguments weren't convincing. Follow Rafael's advice in new smaller PRs to advance this or it'll simply stay closed
    1. Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed? No. Merge requests submitted to this project will be closed automatically.
  19. Jul 2020
  20. May 2020
  21. Apr 2020
    1. This API uses request body in GET requests. For a long time this was prohibited in RFC2616 HTTP specification, but since RFCs 7230-7237, it is only discouraged, since older implementations could reject such requests. However, given that major APIs such as ElasticSearch's already implement GET with request bodies, there is precedence to such implementation.

      My first sighting of the sending a request body with get request.

  22. Mar 2020
    1. When submitting new methods for consideration, it is best if each method (or tightly related set of methods) is in it's own pull request. If you have only one method to submit then a simple commit will do the trick. If you have more than one it best to use separate branches. Let me emphasizes this point because it makes it much more likely that your pull request will be merged. If you submit a bunch of methods in a single pull request, it is very likely that it will not be merged even if methods you submitted are accepted!
  23. Dec 2019
    1. HTTPretty

      Use this to mock the request object so that it will be easier to mock the request context manager.

  24. Nov 2019
    1. this is not intended to become a big, public thing. You're welcome to use anything and steal any code. Please do not count on us adressing feature requests or issues though.
  25. Oct 2019
  26. Aug 2019
  27. Nov 2013
    1. Compared with the 1.0 release, there were relatively few backwards incompatible changes, but there are still a few issues to be aware of with this major release.

      I got all panicky when installing internetarchive via pip caused a move from requests 1.1.0 to 2.0.x -- I had thought that jump was the BIG ONE that broke a lot of other modules. Maybe not.